PersistentSAML2NameIDGenerator fails to see attributes not being released
Description
Environment
IdP 3.1.1
Tomcat 7
CentOS 6.6
OpenJDK 1.7.0_75
Activity
Vlad Mencl May 5, 2015 at 11:36 PM(edited)
Hi,
Sorry, I should have picked it up in the documentation - sorry about the noise.
Cheers,
Vlad
Scott Cantor May 5, 2015 at 1:50 PM
I realize it's tripping people, but it's unavoidable at the moment, it's a consequence of splitting up attributes and NameID generation. I've discussed it on the list at length a few times and updated documentation to mention it.
By the time any of the new code runs, attribute filtering is already done. There's no functional issue, you just have to release a source attribute with no encoders attached, and everything works like it did before.
Bear in mind that here in the US, persistent IDs are essentially undeployed and since they work badly with the majority of applications, that's pretty much a good thing. The new feature was focused on the cases that cause people so many problems, which are custom NameIDs based on real data that naturally involve "releasing" some underlying attribute like an email address. It makes more sense there than it does in this edge case so I didn't notice it until very late in the cycle.
If we come up with a way to revisit the problem, probably by exposing the unfiltered attribute set somehow, we can try something then and it should work fine alongside whatever people are doing in the meantime and not break anything.
Hi,
I'm trying to get my head around using persistent ID as a NameID instead of the eduPersonTargetedID attribute (OID 1.3.6.1.4.1.5923.1.1.1.10).
I've started editing saml-nameid.properties and saml-nameid.xml - uncommenting the bean ref ````<ref bean="shibboleth.SAML2PersistentGenerator" />```` and setting
idp.persistentId.sourceAttribute
idp.persistentId.salt
and also setting
idp.nameid.saml2.default = urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
I used ```uid``` as the source attribute. I already did have uid imported as an IdP attribute from LDAP (````<resolver:AttributeDefinition id="uid" xsi:type="ad:Simple" sourceAttributeID="uid">````), but PersistentSAML2NameIDGenerator was failing with:
2015-05-05 15:32:04,840 - DEBUG [net.shibboleth.idp.saml.nameid.impl.PersistentSAML2NameIDGenerator:189] - Checking for source attribute uid 2015-05-05 15:32:04,841 - INFO [net.shibboleth.idp.saml.nameid.impl.PersistentSAML2NameIDGenerator:218] - Attribute sources [uid] did not produce a usable source identifierIt started working after I explictly released the attribute in attribute-filter.xml
I can see in PersistentSAML2NameIDGenerator.getIdentifier() that the attribute is being looked up in the AttributeContext retrieved from the ProfileContext.
I would understand why the attribute is not found if the attribute filter removes it, but to me as a deployer, this seems to be a bug.
I should be able to define PersistentNameID based on a source attribute without having to release the source attribute.
I can still imagine a workaround like defining the attribute without any encoder, but that makes it a hack...
Did I get right what's happening?
And is there a reasonable fix for it?
Thanks a lot in advance for getting back to me!
Cheers,
Vlad