This topic has 3 replies, 3 voices, and was last updated 5 years, 5 months ago by Peter Major.

  • Author
  • #16061
     Jim Mulvey

    I am trying to use Shibboleth as an IDP and OpenAM as a SP. I would like to use the uid attribute (which is not the NameID) for Auto Federation. I have Auto Federation enabled on my SP configuration, and I’ve entered “uid” as the attribute. One additional item perhaps worth mentioning is that I’m using “Required” for User Profile settings, and my datastore is an Active Directory global catalog (non-writable). I’m using userPrincipalName as the user Search Attribute.

    However, I get the following puzzling entries in my Federation log:
    DefaultLibrarySPAccountMapper.getAttribute: attribute Name =uid
    DefaultLibrarySPAccountMapper.getAutoFedUser: Auto federation attribute is not specified as an attribute.
    DefaultLibrarySPAccountMapper.getAutoFedUser: NameID as SP UserID was not enabled and auto federation attribute uid was not found in the Assertion

    I have reviewed the SAML response from Shibboleth and indeed the attribute is there:
    <saml2:Attribute NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” Name=”urn:oid:0.9.2342.19200300.100.1.1″ FriendlyName=”uid”><saml2:AttributeValue>[email protected]</saml2:AttributeValue>

    I’m confused about what this error means. “is not specified as an attribute”… where?

    • This topic was modified 5 years, 5 months ago by Jim Mulvey.
     Jim Mulvey

    I thought I would follow-up on this, in case anyone stumbles onto this thread in the future. I found that my Shibboleth IdP was sending “uid” as as the “FriendlyName”, but “urn:oid:0.9.2342.19200300.100.1.1” was the actual value I needed to input in as the Auto Federation Attribute.

    I had tried this in the past, and it didn’t work, but I think it didn’t work because I had not *also* added a mapping to map “urn:oid:0.9.2342.19200300.100.1.1” to the actual attribute I’m using as the user ID in my datastore.



    Appreciate the follow up. That will benefit others as well.


     Peter Major

    The auto federation attribute on its own doesn’t tell much to OpenAM, it will know what attribute it needs to look at in the assertion, but it won’t be clear which attribute that maps to in the configured user data store. By adding an attribute mapping setting for that attribute you make sure that OpenAM knows how to look up the user based on that magic “urn:oid:0.9.2342.19200300.100.1.1” attribute.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?