Subject NameID format question

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Subject NameID format question

bmathis@pima.edu

I have set setup SSO for couple of applications where the SP requires  Subject NameID format to be Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"

I'm able to do this successfully only if I release a specific attribute that's defined in my attribute-resolver.xml  as "user_id"   e.g.

   <resolver:AttributeDefinition xsi:type="ad:Template" id="user_id">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
    <ad:SourceAttribute>mail</ad:SourceAttribute>
</resolver:AttributeDefinition>


The part I don't understand is this I have at least 2 other attributes definitions in the attribute-resolver.xml that do not work if I release them instead,  such as the attribute "frshid"

<resolver:AttributeDefinition xsi:type="ad:Template" id="frshid">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
    <ad:SourceAttribute>mail</ad:SourceAttribute>
</resolver:AttributeDefinition>


Here a snippet of the Subject from a SAML trace when it works releasing the attribute "user_id"

<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
             NameQualifier="https://idp.pima.edu/idp/shibboleth"
             >[hidden email]</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="144.90.132.76"
                              InResponseTo="id191289947414822031926171130"
                              NotOnOrAfter="2019-11-05T16:09:32.123Z"
                              Recipient="https://adbe-4bf37e265d9f449a0a495ce8-cdcd-prd.okta.com/auth/saml20/accauthlinktest"
                              />
</saml2:SubjectConfirmation>


Here's a snippet of the Subject from a SAML trace when it doesn't work releasing the attribute "frshid".



<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
             NameQualifier="https://idp.pima.edu/idp/shibboleth"
             >_fedcaab0bd32f85998a32e26b7ed8e73</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="144.90.132.76"
                              InResponseTo="id191277203610250932120081916"
                              NotOnOrAfter="2019-11-05T15:48:05.448Z"
                              Recipient="https://adbe-4bf37e265d9f449a0a495ce8-cdcd-prd.okta.com/auth/saml20/accauthlinktest"
                              />
</saml2:SubjectConfirmation>



Why does it only work when I use the attribute "user_id"?  I'm glad I was able to make it work but not happy that I don't understand why.    I will be happy to answer any questions for further clarification if needed.

Thanks for any feedback.

































Brad Mathis
IT Systems Architect (Acting)
Infrastructure Services - Applications
Pima Community College
520.206.4826








--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Brad Mathis
IT - Principal Systems Analyst
Pima Community College
Tucson, Az
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

sisko
Hi Mathis,

Typically I use the file saml-nameid.xml to set the persistent id generator to use the specified format.
you then only need to release the actual attribute to the sp.  So in this cause you would have a clause in attribute-filter.xml that releases eMailAddress.
Then in the  saml-nameid.xml you could have 2 entries for the sp.

you wil lneed an entry that will tell the generator not to use the default method.
then an entry that says for entityid blah use method xyz.

should be examples in that file.

--
Aterea Brown, AUT University
Cybersecurity, ICT
Email: [hidden email] Phone: 9219999 x 6523

From: users <[hidden email]> on behalf of Mathis, Bradley <[hidden email]>
Sent: Thursday, 14 November 2019 8:05 AM
To: Shib Users <[hidden email]>
Cc: White, Jeff <[hidden email]>
Subject: Subject NameID format question
 

I have set setup SSO for couple of applications where the SP requires  Subject NameID format to be Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"

I'm able to do this successfully only if I release a specific attribute that's defined in my attribute-resolver.xml  as "user_id"   e.g.

   <resolver:AttributeDefinition xsi:type="ad:Template" id="user_id">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
    <ad:SourceAttribute>mail</ad:SourceAttribute>
</resolver:AttributeDefinition>


The part I don't understand is this I have at least 2 other attributes definitions in the attribute-resolver.xml that do not work if I release them instead,  such as the attribute "frshid"

<resolver:AttributeDefinition xsi:type="ad:Template" id="frshid">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
    <ad:SourceAttribute>mail</ad:SourceAttribute>
</resolver:AttributeDefinition>


Here a snippet of the Subject from a SAML trace when it works releasing the attribute "user_id"

<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
             NameQualifier="https://idp.pima.edu/idp/shibboleth"
             >[hidden email]</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="144.90.132.76"
                              InResponseTo="id191289947414822031926171130"
                              NotOnOrAfter="2019-11-05T16:09:32.123Z"
                              Recipient="https://adbe-4bf37e265d9f449a0a495ce8-cdcd-prd.okta.com/auth/saml20/accauthlinktest"
                              />
</saml2:SubjectConfirmation>


Here's a snippet of the Subject from a SAML trace when it doesn't work releasing the attribute "frshid".



<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
             NameQualifier="https://idp.pima.edu/idp/shibboleth"
             >_fedcaab0bd32f85998a32e26b7ed8e73</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="144.90.132.76"
                              InResponseTo="id191277203610250932120081916"
                              NotOnOrAfter="2019-11-05T15:48:05.448Z"
                              Recipient="https://adbe-4bf37e265d9f449a0a495ce8-cdcd-prd.okta.com/auth/saml20/accauthlinktest"
                              />
</saml2:SubjectConfirmation>



Why does it only work when I use the attribute "user_id"?  I'm glad I was able to make it work but not happy that I don't understand why.    I will be happy to answer any questions for further clarification if needed.

Thanks for any feedback.

































Brad Mathis
IT Systems Architect (Acting)
Infrastructure Services - Applications
Pima Community College
520.206.4826








--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

bmathis@pima.edu
Thank you for your response Aterea,   I forgot to mention (and I meant to) .. I'm using idp 2.x ... at least in production.   I do have idp 3.x setup in test and can see the file you are referring to .. and it appears I actually have used that file to help setup SSO for gmail at one point.    Thanks again.

Still looking for any feedback on why things are happening the way they are in my idp 2.x environment.. if anyone has an idea ..

Thanks!

Brad Mathis
IT Systems Architect (Acting)
Infrastructure Services - Applications
Pima Community College
520.206.4826









On Wed, Nov 13, 2019 at 12:29 PM Aterea Brown <[hidden email]> wrote:
Hi Mathis,

Typically I use the file saml-nameid.xml to set the persistent id generator to use the specified format.
you then only need to release the actual attribute to the sp.  So in this cause you would have a clause in attribute-filter.xml that releases eMailAddress.
Then in the  saml-nameid.xml you could have 2 entries for the sp.

you wil lneed an entry that will tell the generator not to use the default method.
then an entry that says for entityid blah use method xyz.

should be examples in that file.

--
Aterea Brown, AUT University
Cybersecurity, ICT
Email: [hidden email] Phone: 9219999 x 6523

From: users <[hidden email]> on behalf of Mathis, Bradley <[hidden email]>
Sent: Thursday, 14 November 2019 8:05 AM
To: Shib Users <[hidden email]>
Cc: White, Jeff <[hidden email]>
Subject: Subject NameID format question
 

I have set setup SSO for couple of applications where the SP requires  Subject NameID format to be Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"

I'm able to do this successfully only if I release a specific attribute that's defined in my attribute-resolver.xml  as "user_id"   e.g.

   <resolver:AttributeDefinition xsi:type="ad:Template" id="user_id">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
    <ad:SourceAttribute>mail</ad:SourceAttribute>
</resolver:AttributeDefinition>


The part I don't understand is this I have at least 2 other attributes definitions in the attribute-resolver.xml that do not work if I release them instead,  such as the attribute "frshid"

<resolver:AttributeDefinition xsi:type="ad:Template" id="frshid">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
    <ad:SourceAttribute>mail</ad:SourceAttribute>
</resolver:AttributeDefinition>


Here a snippet of the Subject from a SAML trace when it works releasing the attribute "user_id"

<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
             NameQualifier="https://idp.pima.edu/idp/shibboleth"
             >[hidden email]</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="144.90.132.76"
                              InResponseTo="id191289947414822031926171130"
                              NotOnOrAfter="2019-11-05T16:09:32.123Z"
                              Recipient="https://adbe-4bf37e265d9f449a0a495ce8-cdcd-prd.okta.com/auth/saml20/accauthlinktest"
                              />
</saml2:SubjectConfirmation>


Here's a snippet of the Subject from a SAML trace when it doesn't work releasing the attribute "frshid".



<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
             NameQualifier="https://idp.pima.edu/idp/shibboleth"
             >_fedcaab0bd32f85998a32e26b7ed8e73</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="144.90.132.76"
                              InResponseTo="id191277203610250932120081916"
                              NotOnOrAfter="2019-11-05T15:48:05.448Z"
                              Recipient="https://adbe-4bf37e265d9f449a0a495ce8-cdcd-prd.okta.com/auth/saml20/accauthlinktest"
                              />
</saml2:SubjectConfirmation>



Why does it only work when I use the attribute "user_id"?  I'm glad I was able to make it work but not happy that I don't understand why.    I will be happy to answer any questions for further clarification if needed.

Thanks for any feedback.

































Brad Mathis
IT Systems Architect (Acting)
Infrastructure Services - Applications
Pima Community College
520.206.4826







--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Brad Mathis
IT - Principal Systems Analyst
Pima Community College
Tucson, Az
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

Peter Schober
In reply to this post by bmathis@pima.edu
* Mathis, Bradley <[hidden email]> [2019-11-13 20:06]:
>    <resolver:AttributeDefinition xsi:type="ad:Template" id="user_id">
>     <resolver:Dependency ref="myLDAP" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
>     <ad:SourceAttribute>mail</ad:SourceAttribute>
> </resolver:AttributeDefinition>

That's a nonsensical use of a "Template" attribute definition, it
doesn't even have a Template element, cf.
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverTemplateAttributeDefinition

So the above at best is a weird way of writing a "Simple" attribute
defintion: Pull in a source attribute and encode it into a NameID.

> The part I don't understand is this I have at least 2 other attributes
> definitions in the attribute-resolver.xml that do not work if I release
> them instead,  such as the attribute "frshid"
>
> <resolver:AttributeDefinition xsi:type="ad:Template" id="frshid">
>     <resolver:Dependency ref="myLDAP" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
>     <ad:SourceAttribute>mail</ad:SourceAttribute>
> </resolver:AttributeDefinition>

That's completely identical to the IDP in every regard with the
exception of the purely internally relevant "id".
So whatever releasing "user_id" in the filter achives must also be
achived by releasing "frshid" in the filter.

> Here a snippet of the Subject from a SAML trace when it works releasing the
> attribute "user_id"
>
> <saml2:Subject>
> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
[...]
> Here's a snippet of the Subject from a SAML trace when it doesn't work
> releasing the attribute "frshid".
>
> <saml2:Subject>
> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"

I have no explanation for that since both seem to be for the SAML SP,
i.e., any rules in your IDP based on metadata or relying-party
overrides would have to apply in both cases (as there's only one
entityID).

> Why does it only work when I use the attribute "user_id"?  I'm glad I was
> able to make it work but not happy that I don't understand why.    I will
> be happy to answer any questions for further clarification if
> needed.

It makes no sense that it would work any differently given the config
snippets provided above, the definitions for "user_id" and "frshid"
are identical (as any diff tool would tell you) besides the id.
Maybe you haven't released frshid in the filter.

Either way, the software you're messing with has been finally and
fully obsoleted 3.5 years ago[1], and we're dealing with security
software here. So you're playing with fire every minute you spend on
something other than replacing that server with one based on a current
release.

Best regards,
-peter

[1] http://shibboleth.net/pipermail/announce/2015-May/000112.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

Peter Schober
In reply to this post by sisko
* Aterea Brown <[hidden email]> [2019-11-13 20:30]:
> Typically I use the file saml-nameid.xml to set the persistent id generator to use the specified format.
> you then only need to release the actual attribute to the sp.  So in
> this cause you would have a clause in attribute-filter.xml that
> releases eMailAddress.

That's fine.

> Then in the  saml-nameid.xml you could have 2 entries for the sp.

There should be no need for that.

> you wil lneed an entry that will tell the generator not to use the default method.
> then an entry that says for entityid blah use method xyz.

Neither for that.

Following the documentation on NameID format selection would be my
recommendation. Most often the best and easiest way to configure
NameID selection is adjusting the SP's metadata, at least in cases
where you have to manage that locally anyway.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

Peter Schober
In reply to this post by Peter Schober
* Peter Schober <[hidden email]> [2019-11-13 21:09]:
> That's completely identical to the IDP in every regard with the
> exception of the purely internally relevant "id".
> So whatever releasing "user_id" in the filter achives must also be
> achived by releasing "frshid" in the filter.

Not sure how the above ended up in my email but the first sentence
should have been something like:

> That's completely identical to the other attribute definition in
> every regard with the exception of the purely internally relevant
> "id".

Best,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

sisko
thanks for the tips!

--
Aterea Brown, AUT University
Cybersecurity, ICT
Email: [hidden email] Phone: 9219999 x 6523

From: users <[hidden email]> on behalf of Peter Schober <[hidden email]>
Sent: Thursday, 14 November 2019 9:14 AM
To: [hidden email] <[hidden email]>
Subject: Re: Subject NameID format question
 
* Peter Schober <[hidden email]> [2019-11-13 21:09]:
> That's completely identical to the IDP in every regard with the
> exception of the purely internally relevant "id".
> So whatever releasing "user_id" in the filter achives must also be
> achived by releasing "frshid" in the filter.

Not sure how the above ended up in my email but the first sentence
should have been something like:

> That's completely identical to the other attribute definition in
> every regard with the exception of the purely internally relevant
> "id".

Best,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Subject NameID format question

bmathis@pima.edu
In reply to this post by Peter Schober
Thanks Peter,  I appreciate your input.  

Brad Mathis
IT Systems Architect (Acting)
Infrastructure Services - Applications
Pima Community College
520.206.4826









On Wed, Nov 13, 2019 at 1:09 PM Peter Schober <[hidden email]> wrote:
* Mathis, Bradley <[hidden email]> [2019-11-13 20:06]:
>    <resolver:AttributeDefinition xsi:type="ad:Template" id="user_id">
>     <resolver:Dependency ref="myLDAP" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
>     <ad:SourceAttribute>mail</ad:SourceAttribute>
> </resolver:AttributeDefinition>

That's a nonsensical use of a "Template" attribute definition, it
doesn't even have a Template element, cf.
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverTemplateAttributeDefinition

So the above at best is a weird way of writing a "Simple" attribute
defintion: Pull in a source attribute and encode it into a NameID.

> The part I don't understand is this I have at least 2 other attributes
> definitions in the attribute-resolver.xml that do not work if I release
> them instead,  such as the attribute "frshid"
>
> <resolver:AttributeDefinition xsi:type="ad:Template" id="frshid">
>     <resolver:Dependency ref="myLDAP" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
>     <ad:SourceAttribute>mail</ad:SourceAttribute>
> </resolver:AttributeDefinition>

That's completely identical to the IDP in every regard with the
exception of the purely internally relevant "id".
So whatever releasing "user_id" in the filter achives must also be
achived by releasing "frshid" in the filter.

> Here a snippet of the Subject from a SAML trace when it works releasing the
> attribute "user_id"
>
> <saml2:Subject>
> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
[...]
> Here's a snippet of the Subject from a SAML trace when it doesn't work
> releasing the attribute "frshid".
>
> <saml2:Subject>
> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"

I have no explanation for that since both seem to be for the SAML SP,
i.e., any rules in your IDP based on metadata or relying-party
overrides would have to apply in both cases (as there's only one
entityID).

> Why does it only work when I use the attribute "user_id"?  I'm glad I was
> able to make it work but not happy that I don't understand why.    I will
> be happy to answer any questions for further clarification if
> needed.

It makes no sense that it would work any differently given the config
snippets provided above, the definitions for "user_id" and "frshid"
are identical (as any diff tool would tell you) besides the id.
Maybe you haven't released frshid in the filter.

Either way, the software you're messing with has been finally and
fully obsoleted 3.5 years ago[1], and we're dealing with security
software here. So you're playing with fire every minute you spend on
something other than replacing that server with one based on a current
release.

Best regards,
-peter

[1] http://shibboleth.net/pipermail/announce/2015-May/000112.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Brad Mathis
IT - Principal Systems Analyst
Pima Community College
Tucson, Az