Unencrypted NameID

[Robert Lamothe]

Hi Scott,
    I'm still trying to get my head around this though my knowledge is growing.  Still, I'm beating my head against a wall.  Here's where I am.
I've uncommented out the bean for email address saml-nameid.xml:
    <!-- SAML 2 NameID Generation -->
    <util:list id="shibboleth.SAML2NameIDGenerators">

        <ref bean="shibboleth.SAML2TransientGenerator" />

        <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
        <!--
        <ref bean="shibboleth.SAML2PersistentGenerator" />
        -->

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
            p:attributeSourceIds="#{ {'mail'} }" />

    </util:list>

I added the following to my attribute-filter.xml:
<afp:AttributeFilterPolicy id="servicenow">
    <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://umassmed.service-now.com" />

    <afp:AttributeRule attributeID="NameID">
      <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>

<afp:AttributeRule attributeID="transientId">
         <afp:DenyValueRule xsi:type="basic:ANY" />
     </afp:AttributeRule>

</afp:AttributeFilterPolicy>

    I suspect that the transientid is unecessary but a colleague suggested it based on what we got from our SP in the metadata which is below:
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
    Reading through CustomNameIDGenerationConfiguration - Identity Provider 3 - Confluence
    I think I have everything in place but I'm still getting a transient string rather than the email address.  What am I missing?

|   |
|   |   |   |   |   |
| CustomNameIDGenerationConfiguration - Identity Provider 3 - ConfluenceOverview An identifier that is neither "transient" nor "persistent" is of a more general category referred to for convenience as a "custom" identifier.  |
|  |
| View on wiki.shibboleth.net | Preview by Yahoo |
|  |
|   |


Thanks-Bob
--
Bob Lamothe
robert_lamothe at yahoo.com
KB1BOB
603-918-6336

 

    On Tuesday, February 2, 2016 5:38 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
 

 > I have not doubt that I'm misunderstanding, documentation seems very
> incomplete so I'm struggling through this at every step.

The documentation simply assumes you know a lot about SAML and has never been written to be approachable without that baseline, that's why most people struggle.

> Ok, so how do I do this?  The vendor is using NameID and wants it to be
> unique, they're recommending it be the email address.

Using email addresses is often a bad idea, and that's not a Shibboleth thing, it's just bad IDM and application practice. It's not really in scope of this list to talk about all the reasons why and the trade offs, but those are things that come from years of experience integrating systems.

Most business integrations tend to rely on internal keys like employee IDs and the like, since they don't have to be globally unique, just unique in a silo.

Email address, despite it being a bad choice, is the de facto standard identifier that happens to be globally unique, that's why people outside higher ed gravitate to it.

Shibboleth prefers the use of SAML Attributes to the NameID element. Vendors are sloppy and don't know what they want most of the time, but requiring NameID isn't unusual, and is the major source of friction using Shibboleth with those use cases.
 
> This suggests that I can override NameID per SP, if so, how do I do this?

https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration

The documentation refers to them as a "custom" NameID. They can be per-SP but they should not be. NameIDs have Formats and a given Format should never be used to carry different data. SPs can request the Format they want, or you have to manipulate the metadata or configuration to ensure the Format desired gets used. You do not want to start creating rules that generate a Format differently by SP, though it's possible.

-- Scott
 
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160211/77d91422/attachment-0001.html>