Populate custom attribute in assertion based on group membership

By: Simon Devlin user 21 Jul 2016 at 10:48 a.m. CDT

7 Responses
Simon Devlin gravatar
Hi, I wonder if anyone can give a pointer about the use of AttributeResolver? I have a need to return a simple string in a SAML assertion. I created a custom attribute, assign that to the user, and provide a value such as BULK_ACTIVATION but this is quite fragile and easy for people to mess up during creation of gluuPerson users. From reading the shibboleth documentation - which is not that clear, it seems that I can use a custom attribute resolver. An example of which for is show below. This maps attributes based on OU membership but for edu. Does anyone have an example of a working custom attribute resolver for Gluu? I'm pretty sure that given a basic one, I can extend it to something that works for me. I presume that I need to use the complex group names, but what about imports etc.? Realise that this probably doesn't fall under the free support, but I'm pretty sure I can take a really basic example and extend it for my use. It's just about where to start. ```<resolver:AttributeDefinition xsi:type="Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="eduPersonAffiliation" sourceAttributeID="eduPersonAffiliation"> <!-- Dependency that provides the source attribute. --> <resolver:Dependency ref="myLDAP" /> <!-- SAML 1 and 2 encoders for the attribute. --> <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:eduPersonAffiliation" /> <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" friendlyName="eduPersonAffiliation" /> <!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed --> <Script><![CDATA[ importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider); // Create attribute to be returned from definition, but iff we have to if (null == eduPersonAffiliation) { eduPersonAffiliation = new BasicAttribute("eduPersonAffiliation"); } // Add at least one value eduPersonAffiliation.getValues().add("affiliate"); // If the user has group membership if (typeof memberOf != "undefined" && memberOf != null ){ // The go through each group membership and add the appropriate affiliation // The IdP will remove duplicate values so we don't need to worry about that here for ( i = 0; memberOf != null && i < memberOf.getValues().size(); i++ ){ value = memberOf.getValues().get(i); if (value.indexOf("OU=Students") > -1){ eduPersonAffiliation.getValues().add("student"); } if (value.indexOf("OU=Teachers") > -1){ eduPersonAffiliation.getValues().add("faculty"); eduPersonAffiliation.getValues().add("staff"); } if (value.indexOf("OU=Staff") > -1){ eduPersonAffiliation.getValues().add("staff"); } } } ]]></Script> </resolver:AttributeDefinition> ```
Rhel72
closed

Answers

By Mohib Zico staff 21 Jul 2016 at 11:31 a.m. CDT

Copy
Mohib Zico gravatar
Hi Simon, In Gluu Server you don't need to modify attribute-resolver file to apply custom attribute in SAML transactions. You need to touch attribute-resolver for creating nameID attribute only. Here is what you can do: - Create custom attribute with Gluu Server's GUI [feature](https://gluu.org/docs/oxtrust/configuration/#attributes) - Use [Cache Refresh](https://gluu.org/docs/oxtrust/configuration/#cache-refresh) to pull 'BULK_ACTIVATION' value from backend AD attribute into this custom attribute. - Release this custom attribute to Trust Relationship for that SP which require 'BULK_ACTIVATION' value. If your backend AD/LDAP server do not have attribute which has 'BULK_ACTIVATION', you can take advantage of Cache Refresh custom script. [1](https://gluu.org/docs/customize/script/#cache-refresh) and [2](https://gluu.org/docs/oxtrust/configuration/#manage-custom-scripts). This will dynamically populate 'BULK_ACTIVATION' at the time of user's population from backend.

By Simon Devlin user 21 Jul 2016 at 11:40 a.m. CDT

Copy
Simon Devlin gravatar
Hi, Thanks for the reply. I'm using the embedded OpenDJ not an external LDAP server. Does the cache refresh stuff still apply in this example? As I have it at the moment, I created the attribute and am releasing a static string. But the attribute values I have to use are hard to type in manually THEY_ARE_QUITE_LONG_AND_COMPLEX and prone to errors if entered manually. It works fine just isn't user friendly, hence the desire to auto-generate an attribute based on group membership.

By Mohib Zico staff 21 Jul 2016 at 11:54 a.m. CDT

Copy
Mohib Zico gravatar
>> I'm using the embedded OpenDJ not an external LDAP server. Does the cache refresh stuff still apply in this example? No. How you are loading new users in your Gluu Server?

By Michael Schwartz Account Admin 21 Jul 2016 at 3:25 p.m. CDT

Copy
Michael Schwartz gravatar
Yes, if you are not using cache refresh, then another solution might be to use SCIM interception scripts, which is available in version 2.4.4. You can try the [beta release](https://ox.gluu.org/doku.php?id=qa:platforms) or wait nine days for the final release.

By Simon Devlin user 22 Jul 2016 at 1:45 a.m. CDT

Copy
Simon Devlin gravatar
Hi Mohib, At the moment they're manually created, and at best would be imported via spreadsheet. Thanks

By Mohib Zico staff 22 Jul 2016 at 4:57 a.m. CDT

Copy
Mohib Zico gravatar
Hi Simon, >> At the moment they're manually created In this case there are couple of ways to populate this custom attribute for your users: - Using [SCIM](https://gluu.org/docs/api/scim-2.0/) while you push new users into your Gluu Server. - You can customized registration script so whenever any user will register, this attribute will be automatically populated for those users. - Using python script to populate this value: - Search for your users and put them in one ldif. - Write a quick python script which will read above ldif and add 'add: someCustomAttribute' for all entries from ldif and output will be in another 'output.ldif' - Run ldapmodify to insert 'output.ldif' into your OpenDJ.

By Simon Devlin user 22 Jul 2016 at 5:21 a.m. CDT

Copy
Simon Devlin gravatar
Thanks. I can see that using automation of some sort or another to populate the attribute would solve the issue that the strings are prone to error when input manually, but it's not very dynamic. If a user moves from one role to another (e.g. they change jobs), the value would need to be updated again, whereas I'm hoping that I can derive this from the users' membership of a standard group defined in Gluu. Therefore, moving a user from one group to another, would at the time the assertions are built return the correct attribute value based on the membership. It's clearly something Shibboleth's attribute resovler supports - it's just a bit arcane when you factor in the gluu specific schema (or at least for me). This is not a major issue for me right now so instead I'll park it in favour of my next question about Spring Security NameID requirements. :-~ Thanks everyone.

Post an answer