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.
Related
I'm quite new to the entire auth design and am still trying to understand how to use keycloak for authentication and authorisation.
Currently from what I understand in order to have authorisation enabled for a client you will need to have it in confidential.
After which I am kind of stuck in terms of how to set which policy for which permission.
I have a few types resources but currently placing them all under a single client for simplicity sake.
For my use case I have a workspace for users. So each workspace can have multiple users with different roles of owner,editor,viewer. And within the workspace there are artifacts. So it is some what like designing an authorisation for Google drive.
Would like some advice on how best to design it.
One way I have thought of is using groups and each workspace is a group. Using it to assign users to each group as a way to use the group policy for permission.
The other is really by creating multiple policy and permission for each artifact/resource and adding user to each policy for each workspace.
Would like any advice on authorisation design or even where to begin reading.
After some research I have come to these conclusion.
Yes these can be done by keycloak though most likely shouldn't be done in keycloak itself for its design.
Keycloak itself will most likely be more suitable in terms of authenticating/authorising on services or infra level. So this use case of having user be able to access workspaces or artifacts will be better done in application level having a separated service to handle the permission itself.
That being said if it really needs to be done in keycloak the design that I thought of that is not so scalable is as follow.
Create a policy/user and each workspace/artifact as a single resource. Depending on how many types of access/fine grain control is needed for each type of resource create the scope for each (e.g workspace:view, workspace:edit...). Then create a permission for each resource&scope. This allows fine grain access of basically assigning user to permission of each resource through the user policy.
But of course this design has its flaws of the need of too many policies, permissions and resources so it is better to have keycloak just handle the authentication part and authorisation is just giving users the role to be able to access a service and through the service check if the user is authorised for a certain action.
I am working on a project that allows a user to create a user to create app keys or secrets so that specific services can be used by external clients. A user can create multiple secrets that they can choose to use across multiple clients.
For this I am planning to create a decoupled auth server that will use identityserver4.
What really holding me back is that I am not sure whether or not I should create an API layer at the auth server. The reason I am considering API at auth server is so that I can create sort of an admin portal client that will give the users a front-end for creating, renewing, and accessing their app keys/secrets. Even the admin portal is going to be a de-coupled angular application.
There are two things that are holding me back at the moment:
I am not sure if it's a good or safe idea to serve this data via
an api layer. From what I understand, identityserver will not be able to provide functionality that allows me to access a list of a user's clients through an endpoint but please correct me if I'm wrong and there's a better way to approach this.
I know we can easily create new clients and persist it into the database with identityserver4 and I am planning to use ClientCredentials grant types for user clients, but is there a link at the database and identity level between a user and a client? Or will I need to create that functionality by myself?
So far I've looked but I have not bee able to find examples that are similar to my situation with identityserver4
Sorry for the noob question, I am just getting into identityserver and web security in general so many of these concepts are still very new to me.
For number 1, I would say yes you can create an API layer to server data. If you check the IdenttiyServer4 AdminUI, Rock Solid has also use the admin API behind the UI. But you must consider encryption, TLS and other security mechanism to keep this safe.
AFIK for number 2, there are no links at identity level between a user and a client. You have to create that by yourselves.
Basically, you need a system that supports Multitenancy. I have achieved that by adding a TenantId field in the AspNetIdentity user table. And also added the tenant Id to claim list.
Please do not hesitate to correct me if i am wrong.
I have followed the tutorial for enforcing policies on API calls
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
It wasn't easy but I got something up and running. I can change access to different endpoints of an API depending on the user's role.
I have a question. Here's a fictional setup to complete the tutorial:
API EduCollege, with endpoints /student/info and /staff/info (tutorial)
API Prison, with endpoints /prisoner/info and /staff/info (note that it's the same endpoint)
I write a policy EDUCollegePolicy that enables only those with role college_admin to access /staff/info (tutorial).
But there seems to be no way to restrict these college admins from accessing staff info of the prison!
The field resource only contains info about the endpoint.
Is there any way, using this setup, to limit by API?
Or does it maybe require a different JAR add-in, that would send a resource value set to API/version/endpoint instead of just /endpoint?
Oh, by the way: I couldn't set policies according to the endpoints provided in the tutorial. It doesn't seem that it's /staff/info, but I got it to work with regexp .*staff.*info.*. Not nice. I wonder what the actual resource sent from JAR to PDP is, I couldn't find it in any logs, including IDS logs (the IDS acts as PDP)
I would like to know if the following scenario is possible:
A Fiware Orion Context Broker instance, to which different data providers connect to publish their data. For each data item (context), the particular data provider should be able to control which application or data consumer is allowed to subscribe to this context. Is this possible with Orion? How can this be done?
I've looked into the multitenant model, but I guess that is not the proper way to do this. Am I right? Are there any alternatives? You can protect the Orion instance with a PEP proxy, but I guess it does not allow access control on a per subscription basis.
Any hints would be highly appreciated.
The scenario that you propose can be implemented, if I understood correctly, with Steelskin PEP Proxy and the multitenant mechanism (but with some concerns).
In your scenario, your whole application would be a service (indicated in all transactions with the fiware-service), and each data-provider would own a dedicated subservice (indicated with the fiwareservicepath header). All the users (both administrator from the data-providers and final user and applications) would be users of that service. Using XACML, different permissions can be assigned to each possible action and user in different roles. E.g.: you can create a dataProvider role with full permissions under its subservice and a dataConsumer role that should be able just to subscribe and read.
This scenario has some problems, mainly concerning who creates the users and roles and assign roles to users. In order to use Steelskin, you have to map services to Keystone Domains and subservices to Keystone Projects; and users belong to the domain. It's the domain (service) administrator the one in charge of creating the users, so, in your case, data providers would not be able to create new users (and probably, even assigning them as subservice customers).
If you need an example on how to connect these pieces together to achieve this, take a look at:
https://github.com/telefonicaid/fiware-pep-steelskin/blob/master/keystoneInstallation.md
Hope it helps
The question I have is that of securing documents across services using RavenDb and the Authorization bundle:
I have an 'Account' service which is responsible for managing all things 'user'.
I have a 'Messaging' service which is responsible for all things 'messaging' i.e. wall posts, conversations etc.
To trace who did what in this service, when a new message is posted I create the message and two UserProxy objects (cut down User objects which only have UserId and UserName properties - these are stored as child objects on the WallPost doc so they aren't documents in their own right)
When a user posts something to another users wall i only want to allow:
delete/edit to the original poster, the recipient and admins
view to original poster, recipient, admins and all friends of the recipient
I also have a media service which is responsible for images/video, a MusicEvent service for all things music event - they all need to have a similar setup.
My question is this:
*should the account service store the master User with Roles and Permissions - when it is asked for a user it can send back a dto with the roles and permissions (could get chunky)
*should the Messaging Service maintain it's own copy of a User - with it's own set of roles and permissions?
first is simpler moving forward as it's centralised - but looks a bit dodgy to me
second is probably better but the issue comes when the AccountService changes the username - i can send an event to the esb and have all the relevant services pick it up and take care of the update - but that sounds complicated.
FTR - i'm swaying to option 2 - the non-centralised method.
Personally, I would think about introducing a third service - e.g. IT / Administration service that would be responsible for Roles and Permissions. Its strikes me that these are different business functions / capabilities to those described in Account or Messaging services. A service responsible for that type of functionality would decouple the security aspects of your services from the actual functional areas of Accounts and Messaging. Accounts could still remain the owner of Account information. The messaging service really only needs to identify the user and so using user id / username here is sufficient, unless it nees aditional user information to do its work (email address perhaps). Its ok to duplicate data in this instance, as long as Accounts remains the owner of information.
Ayende answered this for me quite nicely on his blog:
http://ayende.com/Blog/archive/2011/02/17/distributed-authorization-with-ravendb.aspx