Our system is moving from a monolithic to a microservice architecture.
The microservice architecture comes with technical challenges that we need to address and one of them is AuthN/AuthZ.
Our approach is to have an authentication service that would authenticate users and generate access/refresh tokens (JWTs).
Access tokens would then be passed in request header through the chain of microservices such that each microservice just have to validate the token to determine the user has been successfully authenticated.
For the AuthZ part, permission enforcement is done in the microservice itself. My questions are related to AuthZ.
To illustrate the talk, let’s take a specific example of a receptionist who wants to register a new member to his fidelity program, for instance from a Web application.
To support this use case, let’s assume the system has 2 microservices, the ReceptionService and the MemberService.
The ReceptionService offers one REST API to initiate the member registration flow. It requires user permission “registration” to allow execution.
The MemberService offers one REST API to create a new member resource which is protected by CRUD permissions.
A request flow would be:
The web application, on which the user has previously logged in, sends a member registration request to the ReceptionService API including the user access token in the header.
The ReceptionService validates the user token, ensures user is granted with permission “registration”, does whatever business logic it needs to do, and finally sends a member creation request to the MemberService API including the user access token in the header.
The MemberService validates the user token, ensures user is granted with permission “member.create”, and finally creates the member.
To design a solution for such case, my team worked on the following assumptions/prerequisites:
A microservice must always enforce permission (at least for significant API operation such as creating a member). Thus the CRUD permissions on the MemberService in the example above even if Products Managers might only require the top-level “registration” permission.
A user who is able to start a use case because it has the “top-level”
permission must be able to complete it. Meaning It shall not get
errors because he is lacking another permission from somewhere in the
underlying services’ call chain.
Admin users shall not have to understand the chain of permissions
that is required to perform a use case. In our example, Admins should
be able to provide users only with the “registration” permission.
To be able to complete the above example, there are 2 different permissions to be assigned to the user, which breaks some of our assumptions/prerequisites. To overcome that, one of my colleague proposed to consider declaring microservices as identities/users in our AuthN system so that they could be assigned with the appropriate permissions. The user token initially provided would then be replaced by participating services token among the call chain.
To come back to the example, the new request flow would be:
The web application, on which the user has previously logged in,
sends a member registration request to the ReceptionService API
including the user access token in the header.
The ReceptionService validates the user token, ensures user is
granted with permission “registration”, does whatever business logic
it needs to do, and finally sends a member creation request to the
MemberService API including its own service token in the header (and
so replacing the original user token).
The MemberService validates the service token, ensures service is
granted with permission “member.create”, and finally creates the
member.
With this solution, service’s identities in the AuthN system would be flagged in a way that they are filtered from an Admin user managing permission assignments. Permission assignments to services identities would be pre-defined with no possibility for a user to configure it. While it fulfills our assumptions/pre-requisites, I have few concerns about this approach:
When dealing with the “who did what” (audit), user identity and
service identity provided in the tokens would be listed
indifferently. In our example, the RegistrationService would audit
the actual user who initiated the operation but the MemberService
would audit that the operation was performed by the
“RegistrationService”. In reporting scenarios, it means I would need
to reconciliate audit from both systems to determine “who actually
did create the member” using somehow a correlation ID.
While I understand the need to create an identity for a system
component in scenarios which do not involve an actual user (automated
batch/third party access ..), I am not comfortable with replacing the
user token with a service token in scenarios where a user actually
initiated the use case. Is that a standard design pattern?
Could it be that some of our assumptions/prerequisites just wrong?
For instance, is it really a security hole that some microservices do
not enforce permission even if they are only accessed by others
controlled microservices in a safe environment? Assuming the answer
to the latter is “no, it would not be a security hole”, then what if
tomorrow, I need to make the MemberService API also accessible
outside of the safe environment (for instance, because I make it
available to a third party). I would most likely need to add a
permission on it, which would break my registration flow.
Is it wrong to say we do want Admin users to know which set of
permissions are required for a use case and that we should rather
build the system so it gracefully handles failures due to lack of one
permission in the call chain (maybe using Sagas and compensation
routines)?
Any comment or links to resources would be greatly appreciated.
Thanks!
Each service should own it's own permission-schema, but I would recommend you using Service Mesh to not Authenticate user throughout each hop/Microservice.
Related
I have API backend and it will be consumed by different consumers like our own company website and even other website can use our API with certain quota/limitation and for this scope management we will be using express-gateway(eg), however this is not the only reason I am using express-gateway(eg). Now coming to my problem/miss-understanding, for our own website we can create api-key and user credentials using eg command. But for the other user who wishes to use our api, I don’t want them to contact me for this integration, rather they should be able to create a user credentials and API key themselves using some facility (let us call it key management) provided by us. Here I am stuck how to give a web platform or any other mechanism where a user can create account and then create api-key for their own website. I was thinking to extend the express-gateway app itself and create page where a website owner can fill the form with various input field that will serve as parameter for eg command and I can trigger eg command in node console and create credentials and save it in redis database and then fetch those information to show it to user as their use rid and api-key. But I want to know the best way how others are doing, like how google, twitter and many more are allowing to create api-key, delete key and regenerate the api-key on compromise. Some suggestion would be to use third party tool to manage user-credentials, I will have little inertia to accept that, even if I do so how will I hook those third-party solution to my express-gateway.
In general, API gateways and authentication servers are independent, or at least loosely-coupled. The typical workflow is:
A user browses to the Create Account page for a service.
The user creates an account with the authentication server
The user makes a request through the API gateway
The API gateway checks with the authentication server whether the operation is allowed, discarding it if the user is not authorized to perform the requested action
The API gateway dispatches the request to the appropriate server
The receiving server checks whether the user is permitted to perform the action (in case the API gateway has been compromised)
Express Gateway includes its own authentication server for convenience, but the steps are basically the same. The difference is that one uses the Express Gateway Admin API to create the user and credentials rather than going to a different server.
Note that Express Gateway and its default account database (reddis) are not persistent out of the box.
I'm a bit confused about the role of user_id when creating a new "client" for Laravel/Passport.
I'm using the Authorization Code workflow, where a 3rd party app will access data from my app after the user authorizes it.
From what I understand, this 3rd party app is the "client" and has no reason to be associated with a specific user, as several different users are likely to use it. Am I missing something?
you are right in the case of authorization flow you won't be using it and probably should be on null, because the authorization flow represents a user giving permission to a client to use its data, now remember there is password grants flow, this flow may be used with only one client (the one you have for default on passport:install command) or you can define a more complex structure where the user is represented by a client and so you will need as many clients as users this is rare as it would mean that each user represents an app but depending on the kind of app or service it may be needed this way.
Also there is the client management scenario. As was mentioned before there are use cases where a user could be an "administrator" to that client and so update values or revoke access, etc.
https://github.com/laravel/passport/issues/600.
I am using this googleapis nodejs client for calendar, and everything works perfect except that if I remove access from google account security settings,
calendar is still connected. Is there any method to check for removed access from google account? How to handle those cases?
When a user runs your application the first time they are presented with a consent form. Which asks them to grant permission for your application to access their Google calendar data. From this point on when ever your application runs the user may have to login again but they will not have to grant your application permission. If you have a refresh token you will be able to use that when ever you like to request a new access token. the access token will be valid for one hour.
Now if you request a new access Token as stated its valid for one hour. This is true even if the user goes to Google Account security for their account and removes the consent for an application access their data.
Your still going to be able to access their data while any access tokens you have currently are valid. If the user tries to use your application again they will have to consent permission. If you try to use the refresh token it will no longer work.
Access tokens work for one hour they are not reauthorized during that time its assumed that they are valid. (This may in fact depend upon the scope and API in question and how googles policy server works.)
access token are designed to be self contained permission systems. As long as you have an access token for the correct scope most apis assume that you have access. However in the event this method is accessing critical data then they may have a policy server setup. This server could be doing an extra check on an access token to ensure that the user still has access even though they have a valid access token. However doing this can be very time consuming and resource heavy as reevaluating every call to ensure that the user still has access. It kind of defeats the purpose of having access tokens that are valid for an hour in the first place.
Client sends username and password to the server.
Server then checks if this user is authenticated.
If yes, the server returns an access token for the client...
Then user can use this access token to access protected resources...
The advantage here, is that we are not sending user info via API calls, and the access token will not last for long time, so hackers won't be able to find out user authentication info (user name and password), and if he finds out, the access token won't last long enough to do anything with it.
That's how I understand Laravel passport API security.
The confusing thing here, is that on first API call, user has to send user name and password, so hacker still have big chance to find out user info!!!
I know that there is something wrong with my understanding, and that's why I get confused, any explanation would be very appreciated.
There must be a way to prove your identity to authorization server, and one way is to provide username and password. The way you're gonna achieve communication between authorization server and your client application is totally up to you as long as it uses HTTP. As stated in RFC-6749:
This specification is designed for use with HTTP ([RFC2616]). The
use of OAuth over any protocol other than HTTP is out of scope.
Of course it's always advised to use HTTPS whenever possible. Just because HTTP is mentioned in document, doesn't mean HTTPS cannot be used because HTTPS is just encrypted version of HTTP.
Other thing I wanted to mention is that you don't need to provide username and password, there are several grant types where you can, for example, instead of username and password you can provide client_id and client_secret which is used in Client Credentials grant type.
If you are new to this I believe this all is little bit confusing for you. To summarize the purpose of OAuth2 to you (as far as I get it), is:
To separate role of the client (which can be browser, mobile etc.) from the resource owner (usually the owner of account). Why? Because if there is no separation, the client has access to user's sensitive data.
Imagine that the first point is secure enough for communication. But what happens if someone gets their hands on the session you have? They have access to all! This is why OAuth introduces scopes, where depending on the scope user has with provided access token has limited access to resources. Scope can be read, write, share etc. - this implementation is up to developer. So if someone gets their hands on your access token, because of scope they only have a limited access to resource.
These are one of my reasons, while RFC-6749 has better explanation:
Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.
Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.
Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.
To learn more about OAuth2, it's grant types and purposes, I recommend you to read this:
An Introduction to OAuth 2
Mentioned RFC-6749, even though it can be difficult to read because of technical writing.
Hope I clarified at least a small piece of blur.
We are building an ASP.NET MCV 3 application from scratch running on Windows Azure. About Authentication and Authorization layer we are thinking to use the Access Control Service. I went through some articles about ACS where I got the basic idea but I still have some doubts on it.
My understanding is that using the ACS we outsource the Authentication process to one or more Identity Providers (IP), basically we trust another system (i.e. Microsoft Live ID) to authenticate our users.
The basic process is very straightforward: at authentication stage we redirect (ACS does it) the user to one of our “trusted” IPs, that will redirect the user (with a valid token) to the ACS and eventually to our application.
Here comes a number of questions:
Since we don’t want that all the users with a Live ID account can access to our application, I presume there should be another process to validate that user and checking if he is registered in our application. The question is where? In the ACS or in our application?
I have an idea about this but I don’t know if it’s the right way to do it:
At registration stage, the system (our web app.) asks the user which IP (i.e. Live ID, Google, Facebook, and our app.) he wants to use to authenticate himself in the application. Then the user goes through the authentication process on the IP system and when he comes back, we store his username (IP username) in our DB.
So, next time, at authentication stage we can check if that user is registered in our system.
If the above theory is correct, that means in our app. we need to build our membership provider to store usernames coming from IPs and users that chose our app. as IP.
Am I correct? What is the best practice to design the above process?
Now let’s talk about Authorization and “Roles”. How does it work with ACS? Does ACS manage multiple roles per user?
Again my understanding is that with ACS you can create a number of “Rule groups” related to the IP and not to a single user. If this is correct, how do we manage users in role in our application? Let’s say, for example, that we have multiple roles and our users can be associated to those roles, can we use ASC to manage it?
So the final questions are: Does ACS itself cover the whole Authentication and Authorization process? Do we still need to use the .net Membership Provider? What's the best practice in order to cover our requirements?
For the part of the question about the registration stage, the best thing to use to identify users is the NameIdentifier claim type
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.
This should be unique for each identity provider and also fixed. If you use the email address claim, it could change for the same user. Technically it could be possible for two identity providers to use the same NameIdentifier (none of the out-of-the-box ones with ACS do) so you could combine the NameIdentifier claim with the IdentityProvider claim type
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
to guarantee uniqueness.
For the part about role, I would say using ACS to issue role claims from generic identity like Google would be quite hard to manage using the claim transformation rules in ACS on per user basis. You would have to add a rule for each registered user - probably not feasible. I think the ACS rule groups are more suited to transformation of role claims (e.g. issued by a federated ADFS). Your idea to do it in your application is a better one IMHO. In code, the place to do this using WIF is in a custom ClaimsAuthenticationManager. You override its Authenticate method and based on the NameIdentifier claim from the incoming principle, you look up in your membership datastore and create a new IClaimsPrinciple based on the roles that are in your membership DB (i.e. you add a role claim for each role the user is in).
You then make your authorization decision in a custom ClaimsAuthorizationManager. There are some good samples and info on this around on the web. You can start at
http://msdn.microsoft.com/en-us/library/ee748497.aspx
The user validation process is done with claims.
After you set up an IP with ACS, when users authenticate, ACS will get claims about the authenticated user from the IP. You need to configure rules in ACS to say which claims you want forwarded on to your application. You can also tranlate claims into different types, to normalize the incoming claim set to what your application expects
If you want to implement your role based access with ACS, you can. In this case a role just another claim ACS will issue, and you'll implement your application to give user privileges based on the role claim it receives from ACS.
You can configure ACS rules that map certain IP input claims to role output claims. ACS also has a management service that can change these rules so you can implement a user registration process.
Individual claim rules in ACS relate to identity providers that issue the claim, but rule groups don't. Rule groups associate to RPs (your applications). A rule group is simply a group of claims transformation rules that tell ACS: "for this application, apply this rule group policy when you issue the token".
The ACS docs have lots to say about ACS claim rules configuration, both through the web portal and through the management service::
https://msdn.microsoft.com/library/azure/hh147631.aspx
Expanded response:
Let's say you're using ACS to authenticate to an ASP.NET app that's using WIF. You would configure ACS to issue a Role claim of "Manager" for the google user with email "jdoe#gmail.com".
Now in your ASP.NET app, WIF will see this role claim and it will allow you to control access using either HttpContext.Current.User.IsInRole("Manager"), or the web.config equivalent.
You can manage these ACS rules manually using the web UI, or you can implement a registration process that adds such rules to ACS programatically using the ACS management service. There are some ACS management service samples available at acs.codeplex.com.
Also, the identity developer training kit has some examples on WIF role based access:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347