Question
I am trying to find a good way to struct the permissions of my api gateway to be accessed from a external software.
The context
In my current company we have an API gateway.
When a user log in we send all the user permissions to the front-end service and generate all the menus and screens for the current user and what it is allowed to access.
Example:
{
user: joe,
permissions: [
'fancyMenu',
'anotherFancyMenu'
]
}
This approach worked really well, but right now we need to expose the API to other clients and they will access directly our endpoints.
Problem
So previously the user who had access to fancyStuff menu need to access the endpoints x,y,z to complete a operation. Each endpoints has to check if the logged user have the fancyStuff permission.
Now we need to expose our API to other softwares.
In this example the permission fancyMenu needed to access this 3 diferent endpoints to finish the operation. Get some stuff and fancy coins to create a new fancy operation.
fancyMenu -> POST /fancy
fancyMenu -> GET /coins/fancy
fancyMenu -> GET /stuff
Solution
That being said we created a new class on our api gateway and mapped all the menu permissions with the required endpoint.
One example is our menu fancyMenu now have a list of all endpoints that are required to do its all functionalities and we check this new class on all endpoints.
I am not sure if this is the right approach for the problem, but I couldn't find a better one.
Related
I am using Identityserver4 for AuthZ and AuthN and trying to understand the purpose of scopes for a webapi
I am implementing a first party application an internal application which will works in intranet. so there will be no consent page.
image : application architecture
I have 3 users
User X : who can perform read and write operation on Web API ‘A’ Only
User Y : who can perform read and write operation on Web API ‘B’ Only
User Z : who can perform read and write operation on both Web API ‘A’ and ‘B’
Since all the user will log in using the ‘Angular front end’. In the front at the time of login the scopes requested must be like below
{
response: code
scopes : ‘openid A:read A:write B:read B:write’
}
As I said earlier, I am using Identityserver4 once the user successful logins the client will receive Id_token and access_token.
I understood from different article that api will check for the scope to provide access to an operation like read and write. So,
If User X logs in, access_token should contain scope only A:read, A:write
If User Y logs in, access_token should contain scope only B:read, B:write
If User Z logs in, access_token should contain scope only A:read, A:write, B:read, B:write
Since ‘Angular front UI’ is same for all the 3 users (X, Y, Z) in my case.
Client will request all the scopes (A:read, A:write, B:read, B:write) is this correct ?
Do I need to write any custom logic when access_token is getting generated, its should include only scope that user is entitled too?
If I have to write this custom logic which interface I need to implement. is it IProfileService?. i have to use something like role to find out the scopes?
Lastly, in other word, scopes for an web api is nothing but permissions am I right?
In IdentityServer I would create one ApiScope (perhaps named ApiAccess). Then I would create two ApiResources, one for each API and associate them with the ApiScope created earlier.
Then have a UserClaim (perhaps named access) associated with the ApiScope, that contains the particular users access (read or write).
the value for the access claim is then retrieved from the user database.
Also, do see my answer here for a clarification between ApiSope, ApiResources and IdentityResources.
To complement this answer, I write a blog post that goes into more detail about this topic:
IdentityServer – IdentityResource vs. ApiResource vs. ApiScope
I'm designing the architecture for a college project and I don't know how to deal with the user authentication and authorization part of it. The project is a desktop Electron app which would need two types (hence the roles) of users. They both need to be authenticated in order to use the app, and depending on their identity, they will have different authorizations. Since the project is meant to be used by teachers and students as part of a laboratory class after it is done, I don't think more than 30 people will be using it at the same time.
My first thought was using a PostrgeSQL database in AWS for this and implementing the authentication myself, but this means that users will have to sign up and create a new profile, which means remembering yet another <username/email, password>. Trying to avoid this, I read a bit about OAuth 2.0 and OIDC, and how it can be used to authenticate and authorize users without implementing either of those tasks oneself, but rather delegating the task to OIDC. I created a free account with Auth0 and thought about using it for the OIDC integration but after reading about 40 pages of an "OIDC integration handbook" they offer for free, I could not know if I would be able to distinguish my user base through these roles or tags as I mentioned. I just followed the steps in the tutorial handbook and tried to understand how the auth flow worked, but that didn't give me any information on my question.
So all in all what I want to know is: is it possible to implement this with Auth0 (free account) without having to use a third-party database solution (such as PostgreSQL with AWS)? If not, what would you recommend me to look into? Preferrably a solution that will let me discriminate between the two types of users BUT at the same time taking advantage of the OIDC implementation of Google for example.
There are 2 separate solutions here:
DESKTOP AUTHENTICATION
The 2 standard requirements are:
Use Authorization Code Flow (PKCE)
Login via System Browser
You listen for a login response via one of these mechanisms (I prefer the latter):
Loopback web server
Private URI scheme OS notification
My blog has some tutorials + code samples that use Electron. You can run both of the above listening options and see what you prefer.
API AUTHORIZATION WITH ROLES
You need to make roles available to the API via claims. This can be done by either of these mechanisms (I prefer the latter):
Including roles in access tokens via Auth0
Get the API to read user roles from its own database
My Authorization blog post discusses building up a claims object in an easy to extend way. The main objective is usually for API OAuth processing to result in an object something like this:
class UserPrincipal {
// The technical user id from the access token
string sub;
// The user id from your own database
string userId;
// The user's roles
string[] roles;
}
Given that object you can do things like this:
Use role based authorization when needed
Serve up user resources after login from your application data
TO SUMMARISE
Auth0 will meet some of your requirements and may be all you need in the early days. You will probably need to manage non OAuth user data in your API at some point though.
Happy to answer any follow up questions ..
I have a bunch of microservices running. I have an api gateway that connect consumers to all these services. Now on some services I need to give permission to certain users ( users are stored in separate Users Service ). For example if I have a blog service I need to give blog 1, blog 2 and blog 3 view permissions only to user 1 and not to user 2 ( the scenario is acl rather than RBAC or ABAC i think, correct me if i am worng ). Now how should i implement the permission system.
For example If store the permission on each entity object inside each microservice as suggested here then each of my service has to know about users also to grant them permissions. this scenario will compel me to synchronize the users data across all microservices ( on users delete update ... ).
Another Solution is to create a separate generic authorization service to manage all services permissions. but this solution will require me to save each microservice schema ( and have to synchronize that schema on change )
Or there is any other solution. please help. how to implement ACL (authorization)
One solution would be to introduce userID into the downstream path from the gateway. So the path
GET /blogs/{blogId}
is exposed on the gateway, but this becomes
GET /blogs/{userId}/{blogId}
on the blogs microservice. The gateway handles the user's bearer token and injects the user's ID into the downstrteam call. The blogs microservice would then return the blog for a "valid" path, or a 404 if the path was not valid.
This is illustrated here:
the backend service maintains which users have access to which blogs?
The blog microservice stores and manages blogs. A blog can have an access list associated with it. That list may contain only the user who is the blog owner, or more than one user. The point is that the ACL is not centralised, but distributed with each blog's data containing it.
if a user is deleted
Then you have two choices. If the user is deleted you publish a UserDeleted event, to which the blogs service is subscribed. Then you can manage all the blogs which have the user in their ACL and remove them. Or, you can do nothing. I would personally choose the latter; one of the features of having a microservice architecture is that some data will not be consistent. If you require absolute consistency then you can have a "caretaker" process which removes deleted users out of blog ACLs. Or don't use microservices.
Suppose that I have a web application. Consider it like a Black-Box for now. I want to use a backend system to limit what a user can view/do on the app.
i.e. Sample users can only do three functions, Premium users can do 10 functions and see more pictures.
What is the best way to do it?
I'm trying to using WSO2 Identity Server, but it doesn't offer this functionality. So I've thought that maybe I can integrate it with the WSO2 API Manager and make an API that limits users' access to a certain resource. But really I cannot find if it's possible do it. Anyone know it?
Please refer to : https://docs.wso2.com/display/IS530/Access+Control+Concepts
1) WSO2IS can act as a coarse grained access manager. Your application will act as a fine grained access mnager.
It means that roles can be defined in WSO2IS, managed and assigned to user. From there Roles assigned to one user can be provided as clains with the identity token generated by WSO2IS and sent to the application.
The application, on the other side, will manage roles to permissions links.
Access control is then done at each request by the application, based on the roles presented in the Identity Token by the user and the Permissions grid based on roles in the application.
2) The access control at the application is a business logic you must implement (or at least configure if it a COTS). It is possible to outsource this logic to WSO2IS as policies on attribute (with Workflows).
Please look at : https://docs.wso2.com/display/IS530/XACML+Architecture
Jeff
When passing Api request to this URL
https://www.google.com/m8/feeds/contacts/default/full
A screen comes requesting this permissions. Is there any URL that just only asks user to "retrieve you contacts" instead of managing it.
SHOPBOX.IO is requesting permission to:
Manage your contacts
Perform these operations when I'm not using the application
The permissions the user is asked for at the authorization screen is dependent on the scope that you specify. Of course for accessing different endpoints you have to request certain scopes.
For accessing the Google's Contacts API this scope is required:
https://www.google.com/m8/feeds - read/write access to Contacts and Contact Groups
As this is your only option and there is no read-only scope available, the user gets warned that you could edit his contacts, even if you won't do that.