Need some clarification whether you can limit access to clients/service provider from IdP?

By: Neemesh Patel user 17 May 2016 at 4:09 p.m. CDT

4 Responses
Neemesh Patel gravatar
I was wondering if someone could clarify something for me. Is it possible to restrict a user's permissions or access to a client/service provider (SP) from the Identidty Provider (IdP) side, or if all clients/SPs will always allow access and then it is up to their internal code to decide whether to allow that user in? To try and better explain the question, I've provided an example scenario below. - There is a Gluu server (IdP), a finance system (SP/client system), an email system (SP/client system) and let's say a website CMS (SP/client). - Mark works in Finance and needs access to the finance system and email system under SSO, but he shouldn't access the website CMS in his current role. - David works in PR and needs access to the website CMS and email under SSO, , but he shouldn't access the finance system in his current role. Is it possible (and if so how?) to configure Mark and David's accounts within the IdP so they have permission to access the email system, but then only access the systems they need for their job (be that website or finance system)? Or is it the case in SSO, they by default have access to everthing connected to the IdP and then it is up to each individual SP to have their own list of authorised users to determine access (i.e. where the IdP passes custom scopes to the SP and then the SP needs to read these scopes and then redirect them elsewhere if they shouldn't access it)? I hope that makes sense Thanks
closed

Answers

By Aliaksandr Samuseu staff 17 May 2016 at 4:21 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Neemesh. >it is up to each individual SP to have their own list of authorised users to determine access Yes, that's how it's intended to work. Authorization is usually taken care of by SP/RP. Though UMA (which is supported by Gluu) is capable of doing authorization too, but you'll need to implement its logic through custom scripts yourself. Regards, Alex.

By Michael Schwartz Account Admin 17 May 2016 at 4:27 p.m. CDT

Copy
Michael Schwartz gravatar
If you want centralized access management, you need to use an authorization protocol--like OAuth2 or UMA--not an authentication protocol. You will also have to update your application to rely on the OAuth2 token (i.e. the application would be the OAuth2 Resource Server). Once the user has a SAML session, you can't do much about it.

By Aliaksandr Samuseu staff 17 May 2016 at 5:53 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
You _may_ be able to implement some kind of authz policy by using Shibboleth's [attribute filters feature](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttributeFilter) (by checking user's group for example and not sending any attributes at all to this SP if it's not in a specific group), but this would require a lot of customizations done to configuration files' templates, would be limited to SAML only, is not recommended and is not covered by free support. You should refer to Shibboleth documentation for that.

By Neemesh Patel user 18 May 2016 at 10:53 a.m. CDT

Copy
Neemesh Patel gravatar
Great, thanks for the info.

Post an answer