nameID attribute not showing up in SP request

[Stein, Eric]

Is there a way for Shibboleth SP to log the incoming assertion? Right now I have to take the client's word about what they are sending.
If the String decoder works, I'll probably switch back to that. And I'll troll the logs again for anything hinky, but I'm pretty sure I won't find anything.

I'll give some pushback on the format of the nameID. I suspected it didn't make any sense.

Thanks,
Eric

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, June 24, 2013 3:27 PM
To: Shib Users
Subject: Re: nameID attribute not showing up in SP request

On 6/24/13 2:21 PM, "Stein, Eric" <steine at locustec.com> wrote:

>Thanks, Scott. I found the relevant documentation. I do have a 
>follow-up question, though.

Before addressing that, note that I misremembered. The "String" decoder does work on NameID elements, as long as the element content is all you need to pull out. So if that didn't work, something is wrong with your config or you're mistaken about the assertion content.

> The incoming value is in the format "uid=XXXXX", and there's a strong 
>likelihood of other information being put in there also. It looks like 
>the "expected" format for the nameID decoders is an email address, and 
>the documentation talks about splitting on @ to determine the name and 
>the scope or the name and the name qualifier.

I don't know what you refer to, but that's not correct. NameIDs are of all sorts and formats, there is no rule like that.

> It doesn't seem like that's appropriate to the format that my name is 
>coming in as.

No, not for a DN. DNs are not a good format in any case, and uid=X is not a real DN, that's a degenerate RDN treated like a DN. That's all rather silly to use in SAML.

>Now, I've had no say on the format of the nameID.  I may or may not be 
>able to force a change of that format. Is what we're doing wildly wrong 
>in SAML land?

None of the legacy SAML 1.1 formats have much of any relevance or meaning, they're underspecified nonsense for the most part. When the TC wouldn't even agree that a NameID with a format of emailAddress should have to actually *be* an email address, I gave up and treated them as deprecated.

> If not, I guess I should be using the NameID AttributeDecoder with a 
>format of formatter="$Name"?

That's equivalent to the String decoder, yes.

I just saw your message about it not working, so I reiterate, you're not doing something correctly or the assertion doesn't have what you think it does.

I would look for log errors during config load, and then mistakes in the XML like a slightly off format string.

-- Scott


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