Hi, Vlatko. Hard to say where they expect those names to be passed into. Shibboleth uses urn format for names it sends, like **Name="urn:oid:0.9.2342.19200300.100.1.3"**. Though, it also uses friendly names altogether, like **FriendlyName="mail"** so may be they need those to be exactly as specified in this doc. Probably, the best option for you will be to create this custom attribute without the underscore, and then overwrite Shibboleth's template at `/opt/tomcat/conf/shibboleth2/idp/attribute-resolver.xml.vm`, making exception for this one attribute, and setting its "Friendly name" to `saml_token`

Here is our guide on creating custom nameid: [link](https://gluu.org/docs/customize/attributes/#defining-nameid) In your case, it'll be a bit different. You'll be editing Apache Velocity's template of Shibboleth configuration file located here `/opt/tomcat/conf/shibboleth2/idp/attribute-resolver.xml.vm`, so it assumes you are familiar with both. I'm afraid we are already beyond limits of Community Support as of now, so you'll be on your own from now on. You'll need to add your custom attribute without dash to **"if"** clause: ``` if( ! ($attribute.name.equals('transientId') or $attribute.name.equals('samltoken') ) ) ``` Then, add complete definition of it to appropriate place in the template: ``` <resolver:AttributeDefinition xsi:type="ad:Simple" id="samltoken" sourceAttributeID="samltoken"> <resolver:Dependency ref="siteLDAP" ></resolver:Dependency> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:gluu:dir:attribute-def:samltoken" ></resolver:AttributeEncoder> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:samltoken" friendlyName="saml_token" ></resolver:AttributeEncoder> </resolver:AttributeDefinition> ``` As you can see, I set **"friendlyName"** to `saml_token`, while all other references in it still use `samltoken`. It may occur though, that they expect this `saml_token` be used as an attribute's name, not just a friendly name; it may not conform to standards, but may happen with some vendors. In that case you'll need additionally edit this definition. You'll need to experiment with it yourself.

You also need to restart Tomcat for those changes to be applied. After that you should see file generated from your updated template at this location: `/opt/idp/conf/attribute-resolver.xml`.

Thanks, this is complex matter I add ``` if( ! ($attribute.name.equals('transientId') or $attribute.name.equals('samlToken') ) ) <resolver:AttributeDefinition xsi:type="ad:Simple" id="samlToken" sourceAttributeID="samlToken"> <resolver:Dependency ref="siteLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:gluu:dir:attribute-def:samlToken" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:samlToken" friendlyName="saml_token" /> </resolver:AttributeDefinition> end ``` and the result was empty https://server/idp/shibboleth

`/opt/tomcat/logs/velocity.log` and `/opt/idp/logs/idp-process.log` should have some clues. You either broke the template, or resulting Shibboleth's configuration still wasn't correct. Such in-depth modifications usually are not covered by free support, unfortunately. You can study the template and how file generated from it looks like, and figure out how to patch it. Learning a bit about Shibboleth and Apache Velocity may help too.

Hi, Vlatko. Did you have some success? Do you still have some questions left?

I have lot of questions. But it seems like I need to read a book or two in order to continue. It is over-complicated, when all that needs to be done is exchange of two files between SP and IDP. Or there is too much free interpretation/implementation of SAML as protocol around? And the GUI for Gluu lacks proper text description for each text. I will have chat with Betterworks and their support team and write back. Maybe a collection of guides for configuring Gluu for different 3th party SP will help lot of people. Other commercial IDPs makes this look so easy.

> It is over-complicated, when all that needs to be done is exchange of two files between SP and IDP. Or there is too much free interpretation/implementation of SAML as protocol around? SAML is not that finely defined protocol, and there are also a lot of vendor-specific nuances in actual implementations you can meet in real world deployments. Some of them even may implement parts of it in a way that doesn't conform to the specs. Usually you don't need to delve that deep to add SAML SP to Gluu, most of the time it's done in one go through web UI. Sometimes it may need a bit of troubleshooting, logging monitoring, traffic capturing etc. But some SPs may be tricky to configure and may require direct edits to Shibboleth configuration files, intense discussions with their support etc. >Maybe a collection of guides for configuring Gluu for different 3th party SP will help lot of people. You can find several examples in the "Integration" section of [the doc portal](https://gluu.org/docs/). >Other commercial IDPs makes this look so easy. Gluu CE is offered under a bit different business model. We don't charge users for using the actual software, giving them an option to master all intricacies of configuring and managing it themselves, and only offer them a paid support assistance as an alternative. We also provide a decent amount of information via documentation and this support portal free of charge, in addition to other publicly accessible resources (protocol specs, Shibboleth/CAS/OpenDJ docs etc) which should cover almost all their needs. But we can't afford spending that much time on providing detailed guides on all possible integration scenarios like companies acting under fully-commercial business model do. That's just a different kind of offer.

Hi, Vlatko. I'm closing the ticket for now. Feel free to update it later if you'll see some progress with your task.