Tag Info

Hot answers tagged

11

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...


8

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong. Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application. Claim Based identities are more useful, but tend to be ...


8

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use ...


7

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...


5

You don't. You use the authentication and authorization modules provided by your framework. My goto web framework is Python's Flask framework. Flask-Login is an excellent module that provides an easy to use API that handles the bulk of the authentication work. Flask-Security is another module that encompasses Flask-Login as well as various other security ...


5

There are two specific cases why you don't want passwordless sudo: This is a defense mechanism against malicious users who gain access to an administrative account. This can either be through exploitation or due to an admin leaving his workstation unattended without locking his session. Having to re-issue the password when using sudo gives impulsive users ...


5

As @SteveS said, RBAC is an authorization model whereas claims are a way of providing information about a user. It generalizes the notion of a role. In the past identity servers would simply provide applications the username and the list of roles/groups. Claims generalize this such that any user attribute can be passed on to the consuming application. The ...


5

If you know what you're doing, using WCF isn't difficult. If you know what you're doing, using WCF with an STS isn't terribly difficult. If you don't know what you're doing it's all terribly difficult. Who am I kidding, it's WCF, so it's all difficult. :) Generally speaking your architecture falls into the federated trust category, as you're using the STS ...


5

Disclaimer: I work for Axiomatics, the leading ABAC/XACML vendor. I am glad to hear you are sold on the philosophy of ABAC. If you haven't already done so, do check out the following resources (I'll spare you commercial links): NIST ABAC project page and report. OASIS' A brief introduction to XACML A quick intro to ABAC with XACML. Gerry Gebel's blog ...


5

How can you know who you authorise if you haven't authenticated? Authentication always comes first, except when everyone is authorised or noone is authorised. Edit: seems like you have two questions now :) 1) You were refused most likely because there is an access control policy that prevents your own original UID from performing an operation on the UID of ...


4

First things first: you are not using the correct terminology. This may be problematic if you are looking for documentation. What you call "authorization" is what the rest of the world calls "authentication". What you call "authentication" is what the rest of the world calls "session management". Authentication is about making sure that whoever is at the ...


4

Your phone or laptop will not necessarily automatically connect to that alternate AP, because even though it has a known SSID, it also has a MAC address which does not necessarily match the one at your home. Whether a given system will be ready to disregard the MAC address change depends on that system (from an explicit experiment at home, I can say that ...


4

I agree with both answers given thus far by Thomas Pornin and Steve DL. Authorization always comes after authentication since authorization is the act of looking at a given user's claims and determining whether the user can do what they are trying to do based on those claims and based on the authorization policies in place. I would like to broaden the ...


3

The NOPASSWD option allows the sudo program to be executed by the sudo user without having to enter a password. It does not imply that your account is password-less. Other users that run su youruser still need to enter the password for youruser. But if you are logged in as youruser (via physical access or over SSH), then you do not have to enter a password ...


3

If you send an email to an address that you find in the SOA, you are not, technically, validating control of the domain; you are validating control of that specific email address. Which is not the same thing. To really validate control of the domain, send a challenge to the purported domain owner: make him create a new entry in the DNS, e.g. a TXT field, or ...


3

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. But will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider). OpenID Connect 1.0 is a simple identity ...


3

The problem with this is that in current practice, e-mail is not really a very secure channel to send this sort of information. There isn't much of a way around this, short of convincing the overwhelming mass of humanity to drastically change its e-mail habits. That's probably never going to happen, so we have to live with it as best we can. If an ...


3

Using the same key for two distinct algorithms incurs the risk of interactions. An extreme example is when you use both AES/CBC for encryption and CBC-MAC as MAC algorithm: if you use the same key for both, then it is pretty obvious that the MAC can be trivially worked around. For AES/CBC + HMAC, the gut feeling of most cryptographers is that the two ...


3

ABAC and CBAC are practically the same thing. Microsoft doesn't call things attributes, but refers to them as claims because attributes tend to be associated with SAML whereas claims are mostly protocol agnostic. XACML is a model/implementation that exposes ABAC, whereas there isn't any concrete CBAC model or implementation -- not from Microsoft anyway. ...


3

Authentication is about identifying who is issuing the command, and making sure that the caller is really that person/system. Authorization occurs necessarily after, since it is about deciding whether the duly authenticated requester should be allowed to proceed or not. In your case with a su command, there are two authentication/authorization. Suppose that ...


2

You can use the TLS/SSL protocol which can provide data confidentiality and data integrity. Combined with HTTP, this gives us HTTPS, which seems to be what you're looking for.


2

Re: tokens Just use a long random string as the token. You can make it exactly as long as you want to. Why would you "encrypt" the user ID to use in the token itself? (Or am I misunderstanding something?) You can optionally also store the user IP and token expiration in the token itself, but these could just as well be in separate DB fields, if you're ...


2

OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer. To some extent you can mix authentication and authorization, but that's a source of confusion. ...


2

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database. This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a ...


2

I think RFC 2616 is quite clear: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the ...


2

CBAC (claims-based access control) and ABAC (attribute-based access control) are essentially the same whereby a claim is an asserted "attribute". For instance, you take an attribute from Active Directory and turn it into a claim. However, there are a few issues with CBAC: first of all, it is a Microsoft-specific term, not a model per se like ABAC or RBAC. ...


2

Well there are a couple options here. The first is to reverse it such that your user has a collection of claims that define which projects they have access to: Claims: Project: 123 Project: 124 Project: 125 Project: 129 This could be unmanageable depending on how often the projects are created and the number of projects per user as you'd have to refresh ...


2

Many people still visit this so here's a very simple diagram to explain it Courtesy Wikipedia


1

You should not have an e-mailed link used for long term authorization as it will likely become compromised over time and the user has no good way to know if it was leaked. The point of sending a password reset link is that the user will know if they lose access to their account and the reset can only be used once. If you want someone to be able to be ...


1

You're suffering from the lack of richness in RBAC. What you really want to consider is attribute-based access control. For instance in this case, you could define rules such as: a user can post in a room he/she is assigned to a user with the role moderator can edit messages in a room he/she is a moderator in a user can edit their own messages... All ...



Only top voted, non community-wiki answers of a minimum length are eligible