64
(1) What is so "bad" about checking Roles for access control? What
benefits are gained by checking for permissions instead?
At the moment of checking, the calling code only needs to know "does user X have permission to perform action Y?".
The calling code does not care about and should not be aware of relationships between roles and permissions.
The ...
18
In response to your first question, the biggest issue with checking that a user has a role rather than a specific permission, is that permissions can be held by multiple roles. As an example to this, a developer might have access to see the developer portal on the company intranet, which is probably also a permission held by their manager. If a user is then ...
14
Authentication and authorization are always good topics
I will try to explain to you how we deal with authorizations in the current multi-tenant service that I am working. The authentication and authorization are token based, using the JSON Web Token open standard. The service exposes a REST API that any kind of client (web, mobile, and desktop applications)...
14
Using another word for "Authorization" or "Authentication" isn't helpful for writing documentation. Even though they're obscure, these two are already the most common words for those things, and any one-word synonym will make your text even less understandable.
Instead you should use phrases to express the same meaning. Authentication means proving to the ...
11
If you use Authorization, be consistent
Some will argue that the following is unnecessary (and not too long ago I would have agreed with them) but, these days, if we use the Authorization header we should inform the type of the token, because API keys are not self-descriptive per se 1.
Why do I think it's necessary and why I do think it's important? ...
11
No you shouldn't use level of access as part of the URI.
There is already a standard way to separate API by user access, and that's with authorization. All users should access the same endpoints, and based on the authenticated user's role, or attributes, you can
Return 401 Unauthorized - If the user is not authenticated
Return 403 Forbidden - If user doesn'...
11
Cookies: in their early version, a text file with a unique client Id
an all the other information needed about the client (e. g. roles)
Cookies are tuples key-value originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web ...
10
Your design seems pretty close to me. Just a couple suggestions.
users - People who will use the system. Here I have usernames and passwords.
Fine
roles - Collection of roles that users can have. Stuff like manager, admin, etc.
Fine too. But you will also need a "UserRoles" entity/table that will tell you which users have which roles. It is ...
10
I would not use or implement RBAC. Instead I would use ABAC. Let me explain...
RBAC or role-based access control is about user management and role assignment. In RBAC, you get to say that Alice is a manager. You can define static permissions along with that. For instance, a manager can approve loans. So there is a link from Alice to manager to approveLoan ...
10
To summarize my understanding of your question, you want: a centralized service that would handle all permissions and ideally this service would omit using the database directly without big performance degradation.
Let’s first address the type of authorization framework you may use.
Authorization Frameworks
RBAC
The most prevalent authorization ...
8
These are intended for scenarios where you have a token issuing authority that is not the same as the application that is the intended recipient.
This may not be different for your application.
But consider a large scaled application. You might have an OAuth or SSO server that's issuing the certificates, and an application that wants a token that shows the ...
7
I store identifier claims only (userid, etc.) (encrypted) in my jwt.
Then when I get the token on the server (API) I can do a lookup server side (db, or local network api call) and retrieve all the associations to the userid (apps,roles, etc.)
However if you want to stuff more into the jwt just be careful with the size since it will likely be sent on each ...
7
I would use a central, unified authentication system and have separate permissions/stats for each microservice (sort of like how I can't yet upvote on this stack exchange site but I can in stack overflow while using the central stack exchange authentication system). One of my current projects will involve this approach in the near future, which will be nice; ...
7
Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)
Your definition of cookie doesn't really describe what they do. A cookie is a key-value pair that is set via HTTP response header (Set-Cookie) by the server and stored by clients that support them. Cookies are sent back ...
6
What are the major risks related to passwords?
The password is not secure enough. This makes it easy, for example, to brute force a password, or simply guess it.
Wrong hashing techniques are used or there is no hashing at all. It makes it easy for anyone who have (think programmers, DBAs, sysadmins) or can get (think SQL Injection) access to the database to ...
6
I bet Tortoise SVN is reading different configuration options than the CLI SVN. SVN can read its configuration from many different sources. I would try playing with settings like store-auth-creds in the per-user INI file or registry.
6
No, you are not using tokens correctly.
The idea is that you have an Auth service which issues tokens and Resource services which can validate the token and read the claims it contains. So the rather than forwarding the bearer token to the auth service each time the flow should be as follows
Client -> Auth : please give me a token, here is my username and ...
6
What you are asking for has a name, a model, and even implementations (open-source libraries as well as commercial products).
Externalized Authorization Management
What you are looking for is called Externalized Authorization Management (Gartner) sometimes also called Dynamic Authorization Management (Kuppinger Cole). EAM lives within the Identity & ...
6
The problem with basic authentication over SSL is it depends on passing reversably-encoded user credentials with every API request. This is a security issue because unless you intend to make the user submit their credentials with every request, you'll have to store the user credentials some way on the client device or in the browser (browsers usually cache ...
6
The short answer is no. From the JWT security point of view, there should not be any problem, since email is an already valid public claim registered in the IANA.
On the other hand ...
I have a user db where each user's unique ID is their email ...
This make the question interesting because there's already a protected claim for users' ID. The claim ...
5
There are many reasons not to use basic authentication scheme to protect Web API services.
In order to use the service, the client needs to keep the password somewhere in clear text to send it along with each request.
The verification of a password should be very slow (to counter brute force attacks), which would hamper scalability of your service. On the ...
5
You are right, OAuth2 is overkill in this specific case and despite the comments, it will add unnecessary complexity to the whole project. That being said, remember that OAuth2 is not an authentication protocol, so one more reason to leave it aside for now. Anyways, take a look to this article and get your own conclusions and decide if it's suitable for you.
...
5
Authentication and Authorisation is a bad example for DDD.
Neither of these things are part of a Domain unless your company creates security products.
The Business or domain requirement is, or should be, "I require role based authentication"
You then check the role before calling a domain function.
Where you have complex requirements such as 'I can edit ...
5
It's sometimes difficult to distinguish between real access control rules and domain invariants borderlining on access control.
Especially, rules that depend on data only available far into the course of a particular piece of domain logic might not easily be extractible out of the domain. Usually, Access Control is called before or after a domain operation ...
5
No, you should not. You should handle the logic for different roles within the method. In your example there will be one exposed method:
pubic void completeDelivery(User user) { ... }
There are a number of reasons for that:
Relying on the user to use your service responsibly is inviting someone to behave badly
It consolidates all the places that need to ...
4
If you are looking for ideas about security for REST web services then look at the OpenAuth spec Appendices describing the "handshake".
http://oauth.net/core/1.0/#anchor27
Creating web services that adhere to OpenAuth standards is probably one of the more secure ways that this can be done. It can give you ideas on authentication, authorization strategies.
...
4
Each microservice should not have to do its own authentication, but it does need to do its own authorization.
Source
And this makes perfect sense. I'm assuming there is no doubt about central authentication. But authorization is pretty confusing.
Considering that number of micro-services can grow upto hundreds, thousands, A central authorization service ...
4
The goal is to have more flexibility by being able to combine multiple providers.
In the past, switching between different providers could be very tricky, and require a rewriting of every application which relied on an old provider. Moreover, if you wanted to be able to query multiple providers, you had to implement that part in the application too.
With ...
4
You can agonize over this issue but I've found the easiest path to a good design is to come at it from the using code.
Don't worry about how easy / hard it is to write. Worry about how it is to use. Can you provide a meaningful abstraction that hides details yet doesn't surprise people? The more effort it takes to explain its use to others the less helpful ...
4
Am I correct in my thinking that HTTP headers is the single correct way to pass auth credentials in a stateless REST API?
No. REST doesn't really address authentication and OAuth uses the query string and POST bodies to get credentials. A header is used for the access token, but this doesn't contain any passwords.
Am I correct that using the URL query ...
Only top voted, non community-wiki answers of a minimum length are eligible
