How can I get the Saml2SecurityToken.Assertion.Subject.NameId in the Subject form the testshib.org test server?

[W O]

Hi,



How can I get the Saml2SecurityToken.Assertion.Subject.NameId in the
Subject form the testshib.org test server? I get exceptions thrown if code
below is not uncommented.



What do I need to configure online or do I need to pass more information in
my metadata.xml file?



Help appreciated.



J.



//if (saml2SecurityToken.Assertion.Subject.NameId == null)

//{

// throw new InvalidDataException("The required NameID
Assertion is null");

//}

//identity.AddClaim(new Claim(Saml2ClaimTypes.NameId,
saml2SecurityToken.Assertion.Subject.NameId.Value));

//if (saml2SecurityToken.Assertion.Subject.NameId.Format ==
null)

//{

// throw new InvalidDataException("The required NameID
Assertion Format is null");

//}

//identity.AddClaim(new Claim(ClaimTypes.NameIdentifier,
saml2SecurityToken.Assertion.Subject.NameId.Value));

[Peter Schober]

Post by W O
How can I get the Saml2SecurityToken.Assertion.Subject.NameId in the
Subject form the testshib.org test server? I get exceptions thrown if code
below is not uncommented.

Logging into the Testshib SP from the Testshib IDP (using the
credentials provided on its login page) and checking the IDP and SP
logs, I just verified that the Testshib IDP does send a transient
NameID in the assertion's Subject.
(It also sends a persistent NameID wrapped in a SAML attribute as part
of the AttributeStatement.)
Feel free to check the Testhib IDP' logs yourself, that's why they're
being made easily available via the web.

How you access a NameID in custom .NET code (I'm guessing) is not an
issue for the Shibboleth list or project.
-peter

[W O]

Hi,

Thank you for your answer. For rd.dev I get:
</ds:Signature>
<saml2:Subject>
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="46.243.26.58"
InResponseTo="_0b651836-f552-430c-90e4-e84e55d4eaa7"
NotOnOrAfter="2014-10-15T11:54:38.962Z" Recipient="
https://rp.dev/Auth/AssertionConsumerService"/>
</saml2:SubjectConfirmation>
</saml2:Subject>

I expect:

<saml:Subject>
* <saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">MyId</saml:NameID>*
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Recipient="
https://rp.dev/Auth/AssertionConsumerService"
NotOnOrAfter="2014-10-15T09:59:04.791Z"
InResponseTo="_fd7d6fef-06a9-48d0-bce1-edd76657a328" />
</saml:SubjectConfirmation>
</saml:Subject>

Maybe my metadata is not correct to instruct the Testshib IDP.

In .NET is a class named public class Saml2SecurityToken : SecurityToken that
does all the 'work'. So if the right information is input, the output will
also be given. However, the input is missing het NameId.

You help is appreciated.

J.

Post by Peter Schober

Post by W O
How can I get the Saml2SecurityToken.Assertion.Subject.NameId in the
Subject form the testshib.org test server? I get exceptions thrown if

code

Post by W O
below is not uncommented.

Logging into the Testshib SP from the Testshib IDP (using the
credentials provided on its login page) and checking the IDP and SP
logs, I just verified that the Testshib IDP does send a transient
NameID in the assertion's Subject.
(It also sends a persistent NameID wrapped in a SAML attribute as part
of the AttributeStatement.)
Feel free to check the Testhib IDP' logs yourself, that's why they're
being made easily available via the web.
How you access a NameID in custom .NET code (I'm guessing) is not an
issue for the Shibboleth list or project.
-peter
--
To unsubscribe from this list send an email to

[Peter Schober]

Post by W O
</ds:Signature>
<saml2:Subject>
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="46.243.26.58"
InResponseTo="_0b651836-f552-430c-90e4-e84e55d4eaa7"
NotOnOrAfter="2014-10-15T11:54:38.962Z" Recipient="
https://rp.dev/Auth/AssertionConsumerService"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml:Subject>
* <saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">MyId</saml:NameID>*

Testshib only announces support for transient NameIDs, as you can see
in the Testshib IDP's metadata. If you're requesting something else
in your SAML2.0 authentication request (my reading of your "I expect"
above) that would explain the absence of the NameID in your case, but
its presence in other cases (like in my test with the Testshib SP).

So stop requesting a NameID format the IDP does not state it supports,
I would expect that to make a difference.
-peter

[Paul Hethmon]

The other point to understand is the format string of:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Is not a format.

It is a way for an SP to convey to an IdP that they do not care what format they receive back. It does not have a meaning like persistent, transient, or email has.

Paul

On Oct 15, 2014, at 8:16 AM, Peter Schober <peter.schober-***@public.gmane.org<mailto:peter.schober-***@public.gmane.org>> wrote:

<saml:Subject>
* <saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">MyId</saml:NameID>*

Testshib only announces support for transient NameIDs, as you can see
in the Testshib IDP's metadata. If you're requesting something else
in your SAML2.0 authentication request (my reading of your "I expect"
above) that would explain the absence of the NameID in your case, but
its presence in other cases (like in my test with the Testshib SP).

So stop requesting a NameID format the IDP does not state it supports,
I would expect that to make a difference.

Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org<mailto:paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org>

[W O]

Thank you! Your help was wonderful. I verified your input and you are
right. So I did upload a new metadata file since I uploaded my meta data a
while ago. After the upload of a the new meta data file I also receive the
NameId as expected.
Thank you for your guidance! Top!

Post by W O
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
Is not a format.
It is a way for an SP to convey to an IdP that they do not care what
format they receive back. It does not have a meaning like persistent,
transient, or email has.
Paul
<saml:Subject>
* <saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">MyId</saml:NameID>*
Testshib only announces support for transient NameIDs, as you can see
in the Testshib IDP's metadata. If you're requesting something else
in your SAML2.0 authentication request (my reading of your "I expect"
above) that would explain the absence of the NameID in your case, but
its presence in other cases (like in my test with the Testshib SP).
So stop requesting a NameID format the IDP does not state it supports,
I would expect that to make a difference.
Paul Hethmon
Chief Software Architect
--
To unsubscribe from this list send an email to