Re: mace:shibboleth:1.0:nameIdentifier in 4.0.1 / SAML 2 ?

[Cantor, Scott E.]

On 1/7/21, 12:36 PM, "users on behalf of Louis Chanouha" <[hidden email] on behalf of [hidden email]> wrote:

>    I'm experiencing issues with Shibboleth 4. It doesn't accept "urn:mace:shibboleth:1.0:nameIdentifier" namePolicy.

Not should it, that's a SAML 1.1 identifier defined by the project in the old days and there is no NameIDPolicy concept in SAML 1.1, nor even a request message. There is no scenario in which it would ever appear in any SAML 2.0 exchange.

Secondly, you don't "ask" for transient, it's a default/fallback used when nothing is needed and in fact has no purpose in SAML 2.0 apart from logout support, which SAML 1.1 did not have either. Its existence in SAML 1.1 was a Shibboleth invention to support attribute queries, which are themselves no longer necessary or used in most cases.

-- Scott


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

[Louis Chanouha]

Thanks for your response !

Is there still a way to make Shibb respond to this nameid request, even with a "ugly hack" ?

Several external services uses this nameid, I will spend a lot of energy making every parties modify their SP.

 

Thanks very much

Louis.

 

Le 2021-01-07 19:00, Cantor, Scott a écrit :

On 1/7/21, 12:36 PM, "users on behalf of Louis Chanouha" <[hidden email] on behalf of [hidden email]> wrote:

>    I'm experiencing issues with Shibboleth 4. It doesn't accept "urn:mace:shibboleth:1.0:nameIdentifier" namePolicy.

Not should it, that's a SAML 1.1 identifier defined by the project in the old days and there is no NameIDPolicy concept in SAML 1.1, nor even a request message. There is no scenario in which it would ever appear in any SAML 2.0 exchange.

Secondly, you don't "ask" for transient, it's a default/fallback used when nothing is needed and in fact has no purpose in SAML 2.0 apart from logout support, which SAML 1.1 did not have either. Its existence in SAML 1.1 was a Shibboleth invention to support attribute queries, which are themselves no longer necessary or used in most cases.

-- Scott

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

[Cantor, Scott E.]

On 1/8/21, 4:02 AM, "users on behalf of Louis Chanouha" <[hidden email] on behalf of [hidden email]> wrote:

>    Is there still a way to make Shibb respond to this nameid request, even with a "ugly hack" ?

Yes, but that's not something I'm going to spend my time describing as it's not a valid configuration.

>    Several external services uses this nameid, I will spend a lot of energy making every parties modify their SP.

I have never heard of anything that *needs* a transient NameID in any Format. That doesn't really make a great deal of sense.

-- Scott


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

[Shibboleth - Users mailing list]

On 1/8/2021 11:31 AM, Cantor, Scott wrote:

   Several external services uses this nameid, I will spend a lot of energy making every parties modify their SP.

I have never heard of anything that *needs* a transient NameID in any Format. That doesn't really make a great deal of sense.

Speaking of not making much sense, we had a pair of SPs that required (yes really) a NameIDFormat of transient but with a "real" value (our net ID). Both had invalid entity IDs (some text plus a GUID) as well, to round out the brokeneity.  Sort of the opposite of what's being asked here.

I think one could work around the original request by defining a SAML2 NameID with the expected format string, and using an attribute for the value from a computedId attribute. You might be in trouble if they need to do any backchannel functions, though.

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