Authorization for SSO setup

By: Conan Malone user 27 Jul 2016 at 4:13 a.m. CDT

7 Responses
Conan Malone gravatar
Hi I'm new to Gluu and SSO but have managed to set up Gluu where I can authenticate users with an external LDAP and have also set up a VM running Shibboleth where I followed the Shibboleth SP ON Centos docs and have that working.. I have a simple page on Shibboleth that has a couple buttons/options (Resource1, Resource2 etc) which will redirect to Gluu login page then if successful login occurs i.e. user exists in LDAP then they are redirected to whatever option they chose (e.g. they click Resource1 button, login then get presented with Resource1 page). Right now anyone in LDAP can access any of the resources but my end goal would be for a set up like this.. User1 is a member of Resource1 group but not Resource2 - He can log in to Resource1 but receives a unauthorized if trying to access Resource2 User2 is a member of Resource2 group but not Resource1 - He can log in to Resource2 but receives a unauthorized if trying to access Resource1 User3 is a member of both Resource groups so can access both groups, he can login to Resource1 and then access Resource2 without the need to additionally login (assuming the SSO session is still existing) More groups/users will exist where some users can access one group, some can access a couple and some can access all etc etc. I was wondering how to go about doing this? Would I need to add users to group within my external LDAP and map the memberOf attribute across to Gluu then somehow get Shibboleth to figure out who can access what? Or would I just create groups within Gluu and add the users to groups within there? Any advice would be of great help, and if anyone knows of tutorials on this exact thing even better!! Thanks in advance, Conan
CentOS72
closed

Answers

By Mohib Zico Account Admin 27 Jul 2016 at 4:43 a.m. CDT

Copy
Mohib Zico gravatar
Hi Conan, I think OpenID Connect + UMA would be your best option. Then again.. if you still prefer SAML.. You can configure you resources as Separate SP ( Logical and Physical ). [This](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationModel) doc is helpful to understand the scenario. After separating resources there in your SP side, you can start distinguishing user with attribute from IDP side. Say... 'authzattr'; it can be multiple valued attribute... whoever has resource1, resource2 or both; can perform authz in that way.

By Conan Malone user 27 Jul 2016 at 5:51 a.m. CDT

Copy
Conan Malone gravatar
Thanks both for the quick replies. I think that has cleared things up a bit better, I guess then that for now I can leave the SP side (Shibboleth) and focus on sending attributes through a SAML response to Shibboleth where I can work out myself later what to do with these attributes. So focusing on the Gluu side how would I go about sending attributes through to the SP? Does the SAML response just automatically send all attributes associated with the user? I have a little python script on the SP side that displays all the headers but can't seem to see any username or anything associated with the user? And finally would the memberOf attribute suffice? As I could just create groups in Gluu (Group1, Group2 etc) make users members of these groups and pass on their memberOf attribute?

By Aliaksandr Samuseu staff 27 Jul 2016 at 5:59 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
As you said before you are already able to authenticate to your test SP using Gluu, you must know how to send attributes, I suppose. Like, you had to create a SAML Trust Relationship in web UI, right? There you have a selection of active attributes you can add to the list of attributes to release.

By Conan Malone user 27 Jul 2016 at 6:11 a.m. CDT

Copy
Conan Malone gravatar
Ahhhh of course, how didn't that occur to me.. Yeah I have set up the trust relationship etc it seems I have just forgot to do the attribute mapping on the Shibboleth end to be able to display them. Thanks for getting me on the right track! Quick question, what does the the memberOf value mean? For my user it has a value of inum=@!D91.... rather than just manager group?

By Aliaksandr Samuseu staff 27 Jul 2016 at 6:39 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
By "my user" you most likely mean your default admin user, correct? For default admin Gluu puts DN of managers group this user belongs to in the `memberOf` attribute. For user entries you create for your own needs you can use this attribute whatever way you like: you can store there the name of the group, or DN of the group in your backend. Just one point to stress out: though you can see controls to manage groups in web UI, Gluu doesn't make that much use of those beyond their application in UMA/SCIM. So for SAML/OIDC you shouldn't create some groups in Gluu, put users in them etc, it isn't supposed to work this way. What you need is to either create or reuse some attribute, be it" memberOf", "myCustomGroup", or "allowedResources", or something else, and populate it somehow with values that will make sense to your RP/SP doing authorizations. As you have some "external LDAP" (I suppose it's your backend), you already are doing some mappings for you users in CR perhaps. If it's not enough to generate values you need, you could write CR script which will process attributes from backend before storing them in Gluu

By Conan Malone user 27 Jul 2016 at 7:50 a.m. CDT

Copy
Conan Malone gravatar
I am using CR to map from a backend yes, I followed the tutorial to retrieve cn, sn, mail, givenName and displayName. I have now added the mappings to Shibboleth in the attribute-map.xml file and can see the correct values for my LDAP user coming through on the SP end so the attributes are definitely working. Would it be possible to map the values from my backend memberOf attribute using CR then use this to pass through to the SP?

By Michael Schwartz Account Admin 27 Jul 2016 at 8:16 a.m. CDT

Copy
Michael Schwartz gravatar
There are probably three approaches that can enable you to centrally manage policy: 1. The application uses claims sent by the IDP to enforce polcies 2. You use a web filter to enforce this policy 3. Your application uses UMA to request the policy decision be made centrally--in the Gluu Server. If you are using the second approach (web filter), you can use either OpenID Connect or SAML. For OpenID Connect, [mod_auth_oidc](https://github.com/pingidentity/mod_auth_openidc) supports the **"require claim"** configuratoin parameter. The Shibboleth SP also has a [Require parameter](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess) UMA is not practical to use unless you can update your applications. Also, if you have mobile applications instead of web applications, your web filter strategy just won't work--you'll need to build the security into your application. In the next six months, Gluu is going to introduce a new set of apache, nginx, and Kong plugins for UMA. This will make it possible to centralize policy management in the Gluu Server, and configure the web server to simply enforce the presence of an authorization token.

Post an answer