Hi Rhett, I think you should avoid that as much as you can because that's not standard. As for example... "SN's" displayname should be "Last Name", not "FirstName". According to standard... "Givenname's" displayname is "FirstName". In Gluu, we try to follow standard developed by consortiums and foundations / boards. Now, you can try to follow w/e SPs want but that will place your IDP in a highly customized/non-standard position which you could easily avoid to just say 'no' sometimes to SPs. :-) But, if there is no other way and you have to modify something in IDP... that's even possible. Please check the integration sections from our doc, [webex](https://www.gluu.org/docs/gluu-server/4.1/integration/saas/webex/) has such requirement.

The SP is a ciriculm vendor and very large. We do not have much sway when it comes to having them correct there usage to match standards, and i have no visibility into why reasons they have for these odd assertions. before we close, let me leave you with some example and let me know if they are something standard but not typical and maybe I'm just trying to map the wrong elements.

<saml2:AttributeStatement> <saml2:Attribute FriendlyName="login_id" Name="login_id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >prichardr</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="email" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >prichard@yyyyy.net</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="givenName" Name="givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >RHETT</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >teacher</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="user_id" Name="id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >domain_prichard</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="familyName" Name="familyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >PRICHARD</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement>

Ive inserted myself into a response they are expecting. My main questions would be, how should a person determine role? we previously looked for certain groups inside of member of, and then assigned a role based on that, but this was something shibboleth did. not something stored inside of ldap. from your previous comment i am assuming that i should create a ldap attribute called role and decide and stash that when the ldap object is placed inside the gluu's ldap, is that correct? Same goes for the above id attribute. It seems to be constructed from the domain and user attributes? Do i understand you correctly, that I should again create a custom ldap attribute and store that? I'm mostly asking for confirmation I am understanding you correctly, as from an ldap perspective it seem odd to store mostly redundant information instead of dynamically creating it from what is already on hand.

Yes, for role or anything ( i.e. memberOf ) has to be attribute and all will be inside ldap. Gluu store all informations regarding users in ldap.