Restrict services per user/groups

By: Jesús JM user 02 Jan 2019 at 9:32 a.m. CST

3 Responses
Jesús JM gravatar
Hi everyone, I am facing issues searching through the docs an answer an access management question. I want to deploy multiple services in my network, and enable SSO on them. But not all the services will be available to all users. I want to implement security levels, since some users will only access a subset of services (e.g. customers). Thus, let's say I have two groups of users: developers and customers, and three services available, A, B and C. Developers will have access to all services, and customers only to service A. I want to implement SSO in a way that if a developer logs in, the session is shared for all services, and if a customer logs in, he/she can access service A but not B or C. I apologise if my question seems simple but I didn't find a response in the docs. I am certainly new in identity & access management and don't know if this is even possible with Gluu framework. I would appreciate if someone can give me some starting point to investigate. Thank you very much! Jesús
Ubuntu 16.04
closed

Answers

By Aliaksandr Samuseu staff 02 Jan 2019 at 9:54 a.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Jesús JM. What you're talking about is called "authorization". Normally, authorization decisions are enforced by **the end service itself**, so it's not something Gluu Service can be responsible for. Usually, you just release some role attribute for each of your users, and your service will either grant or deny access based on its value. So for your developer users "role" attribute will contain "developer", and for customers it will be "customer". There is also option to utilize [UMA](https://gluu.org/docs/ce/3.1.4/admin-guide/uma/) which allows to delegate authorization decision taking to Gluu Server, but it may be an overkill for a simple setup like yours, and will require additional implementation overhead.

By Jesús JM user 03 Jan 2019 at 3:50 a.m. CST

Copy
Jesús JM gravatar
Hi Aliaksandr, Thanks for your quick reply! So, if I understood it right, in an architecture that uses SAML as the protocol for SSO, the authorization policies should be established in the Service Providers (SP) entities, am I correct? I've also checked out UMA and agree with you that it adds certain complexity to the implementation.

By Aliaksandr Samuseu staff 22 Jan 2019 at 5:41 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Jesús. Sorry for the delay. >in an architecture that uses SAML as the protocol for SSO, the authorization policies should be established in the Service Providers (SP) entities, am I correct? Yes, that's it. It's not only just SAML, though, it's the same for OIDC and CAS. IDP/OP/CAS server will just release attributes to requesting party; they can do some rule checking first, to figure out what they are allowed to release, but it's responsibility of the other part to enforce some access policies to its own resources based on the user's personal attributes.

Post an answer