How do I pass a providerid to an IDP, when doing SP-initiated sign-on?
410 views
Skip to first unread message
John Klassa
Oct 23, 2015, 2:45:24 PM10/23/15
to SimpleSAMLphp
First off, thank you for this great bit of software. It looks very comprehensive, and likely does exactly what I'm looking for. On the down side, I'm new to SAML, and am finding the terminology and the sequencing a bit daunting, despite having read the docs, checked the mailing list archive, and even browsed through the source.
That said, I'm hoping this is a simple question, with a simple answer. :-)
Background
I'm attempting to use simplesamlphp as an SP for my application, against a remote IDP (the corporate sign-on service that my company hosts). I'm running simplesamlphp locally, and have it configured with certs that I generated, and with the metadata given to me by the corporate folks. I've asked simplesamlphp to generate metadata for my SP, and have provided it to the corporate folks for inclusion on their end. Finally, I've got the small bit of login test code (from the docs; the stuff that just does SimpleSAML_Auth_Simple with my SP as a parameter) on my machine, and am using it to attempt a round trip.
What I Observe
If I go to the login test page, it does an SP-initiated sign-on. I'm routed to the corporate sign-on box, it authenticates me, and then it sends me back to the login test page. Happy, happy. However, no attributes are present (just an empty array). So, I'm authenticated, but SAML isn't able to give the login test page any information about me...
If, on the other hand, I do an IDP-initiated sign-on -- and provide a "providerid" -- I am able to authenticate, then get routed back to the root of my web server (presumably because the IDP doesn't know where to send me back to, exactly). From there, if I go to the "login test" page, I *do* have an attribute (specifically, a 'name', which is enough for me).
My Question
My question for the list, then, is how do I arrange to have a "providerid" passed along to the IDP, so that (seemingly) some kind of a different profile kicks in, that results in the IDP sending back "name" information -- which it otherwise doesn't?
(I'd pass along snippets of configuration, but I don't know that it would help. I think my question is a more general one...)
To recap, as it is, the round trip works, and I authenticate, and everything is okay except for the lack of attributes in the response from the IDP. It appears that I just need to tell the IDP which 'providerid' I want, and that's what I'm not sure how to do.
Thanks in advance!
John Klassa
Oct 23, 2015, 2:50:39 PM10/23/15
to simple...@googlegroups.com
If I go directly to:
I wind up seeing a ‘name’ attribute. If I let the SP take me to:
via a POST (where the URL is straight from the metadata provided by the corp system), instead, then I don’t get a name.
--
You received this message because you are subscribed to a topic in the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/6IQr1Jjcgso/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.
Tom Scavo
Oct 23, 2015, 2:52:27 PM10/23/15
to simpleSAMLphp
On Fri, Oct 23, 2015 at 2:45 PM, John Klassa <jo...@klassa.com> wrote:
>
> My question for the list, then, is how do I arrange to have a "providerid"
> passed along to the IDP, so that (seemingly) some kind of a different
> profile kicks in, that results in the IDP sending back "name" information --
> which it otherwise doesn't?
This is already happening (apparently unbeknownst to you). Your SP
>
> My question for the list, then, is how do I arrange to have a "providerid"
> passed along to the IDP, so that (seemingly) some kind of a different
> profile kicks in, that results in the IDP sending back "name" information --
> which it otherwise doesn't?
entityID is included in the SAML authn request transmitted to the IdP.
> (I'd pass along snippets of configuration, but I don't know that it would
> help. I think my question is a more general one...)
> To recap, as it is, the round trip works, and I authenticate, and everything
> is okay except for the lack of attributes in the response from the IDP. It
> appears that I just need to tell the IDP which 'providerid' I want, and
> that's what I'm not sure how to do.
Hope this helps,
Tom
Peter Schober
Oct 24, 2015, 7:40:47 AM10/24/15
to SimpleSAMLphp
* John Klassa <jo...@klassa.com> [2015-10-23 20:45]:
when replacing the SAML2.0 defined authentication request with a
proprietary, implementation-specific auth request. (N.B.:
IDP-initiated is not part of any standard).
So that very much sounds like it's an issue at the IDP, as Tom said,
as your SimpleSAMLphp SP software is merely sending a standard SAML2.0
authentication request to the IDP and the IDP responds with that it
thinks is right.
To eliminate out some of the guesswork here: How are you determining
what the IDP sends (in both cases)? Can you reference the exact code
you're using (if you just copied it from the documentation)?
Did you look at the complete SAML response and Assertion the IDP sent,
e.g. using Mozilla Firefox and the SAMLtracer extension? If the IDP
does not encrypt the reponse or assertion likely you'll see exactly
what the IDP sends on the wire, right in your browser.
If so, pay special attention to a Subject element (possibly containing
a NameID element) and to an AttributeStatement element (and its child
elements). Compare those carefully in both cases/approaches.
Background: As the proprietary request sent to the IDP is not fully
equivalent to the SAML-defined one (the latter contains much more
information not supplied to the IDP in the request you showed) maybe
that's the source of the difference. E.g. depending on your SSP
configuration your SP might request a certain NameID (format) from the
IDP in the SAML request. If the IDP didn't support that (and
consequently didn't put one such NameID in the response, possibly no
other format either) *and* your SP was configured to present the
NameID as one of the returned "attributes", that might fully account
for the observed difference.
(Assuming the IDP would assert a certain other NameID [format] when
not asked for one specifically, esp for one it didn't support, which
would likely be the case when using the IDP-initiated approach.)
As a quick test you could set
'NameIDPolicy' => null,
in your 'saml:SP' authsource (in config/authsources.php of your SSP
install) and try again?. That will cause no specific NameID (format)
to be requested in SP-initiated (i.e., SAML-defined) SSO requests.
(If the SAML contains a NameID when using IDP-initiated SSO you could
put that same NameIDFormat into the config element above, so that the
SP requestes the same format the IDP sends. Maybe that'll make it
"work" as expected.=
That all might not make the least bit of a difference (since the IDP
might still not issue a NameID then), and probably you're not looking
at NameID values in your SSP code at all. But it would be one way to
account for the differences based on the SP configuration.
If all else fails it remains just that: An interesting observation
about behaviour of that IDP. I.e., if you want different IDP behaviour
you'd need to talk to the IDP admin. (That would also take out the
guesswork about why specifically the IDP behaves differenty.)
-peter
> My question for the list, then, is how do I arrange to have a
> "providerid" passed along to the IDP, so that (seemingly) some kind
> of a different profile kicks in, that results in the IDP sending
> back "name" information -- which it otherwise doesn't?
That's an interesting observation, an IDP releasing attributes only
> "providerid" passed along to the IDP, so that (seemingly) some kind
> of a different profile kicks in, that results in the IDP sending
> back "name" information -- which it otherwise doesn't?
when replacing the SAML2.0 defined authentication request with a
proprietary, implementation-specific auth request. (N.B.:
IDP-initiated is not part of any standard).
So that very much sounds like it's an issue at the IDP, as Tom said,
as your SimpleSAMLphp SP software is merely sending a standard SAML2.0
authentication request to the IDP and the IDP responds with that it
thinks is right.
To eliminate out some of the guesswork here: How are you determining
what the IDP sends (in both cases)? Can you reference the exact code
you're using (if you just copied it from the documentation)?
Did you look at the complete SAML response and Assertion the IDP sent,
e.g. using Mozilla Firefox and the SAMLtracer extension? If the IDP
does not encrypt the reponse or assertion likely you'll see exactly
what the IDP sends on the wire, right in your browser.
If so, pay special attention to a Subject element (possibly containing
a NameID element) and to an AttributeStatement element (and its child
elements). Compare those carefully in both cases/approaches.
Background: As the proprietary request sent to the IDP is not fully
equivalent to the SAML-defined one (the latter contains much more
information not supplied to the IDP in the request you showed) maybe
that's the source of the difference. E.g. depending on your SSP
configuration your SP might request a certain NameID (format) from the
IDP in the SAML request. If the IDP didn't support that (and
consequently didn't put one such NameID in the response, possibly no
other format either) *and* your SP was configured to present the
NameID as one of the returned "attributes", that might fully account
for the observed difference.
(Assuming the IDP would assert a certain other NameID [format] when
not asked for one specifically, esp for one it didn't support, which
would likely be the case when using the IDP-initiated approach.)
As a quick test you could set
'NameIDPolicy' => null,
in your 'saml:SP' authsource (in config/authsources.php of your SSP
install) and try again?. That will cause no specific NameID (format)
to be requested in SP-initiated (i.e., SAML-defined) SSO requests.
(If the SAML contains a NameID when using IDP-initiated SSO you could
put that same NameIDFormat into the config element above, so that the
SP requestes the same format the IDP sends. Maybe that'll make it
"work" as expected.=
That all might not make the least bit of a difference (since the IDP
might still not issue a NameID then), and probably you're not looking
at NameID values in your SSP code at all. But it would be one way to
account for the differences based on the SP configuration.
If all else fails it remains just that: An interesting observation
about behaviour of that IDP. I.e., if you want different IDP behaviour
you'd need to talk to the IDP admin. (That would also take out the
guesswork about why specifically the IDP behaves differenty.)
-peter
John Klassa
Oct 24, 2015, 9:44:41 AM10/24/15
to simple...@googlegroups.com
Hi Peter,
> To eliminate out some of the guesswork here: How are you determining
> what the IDP sends (in both cases)? Can you reference the exact code
> you're using (if you just copied it from the documentation)?
> Did you look at the complete SAML response and Assertion the IDP sent,
> e.g. using Mozilla Firefox and the SAMLtracer extension? If the IDP
> does not encrypt the reponse or assertion likely you'll see exactly
> what the IDP sends on the wire, right in your browser.
> If so, pay special attention to a Subject element (possibly containing
> a NameID element) and to an AttributeStatement element (and its child
> elements). Compare those carefully in both cases/approaches.
> Background: As the proprietary request sent to the IDP is not fully
> equivalent to the SAML-defined one
> As a quick test you could set
> 'NameIDPolicy' => null,
> in your 'saml:SP' authsource (in config/authsources.php of your SSP
> install) and try again?.
Bingo… Setting NameIDPolicy to null did the trick!
> 'NameIDPolicy' => null,
> in your 'saml:SP' authsource (in config/authsources.php of your SSP
> install) and try again?.
So, it sounds like in some fashion, either:
1. The SP requested a name format that the IDP didn’t support, and so the IDP wasn’t able to give back a suitable answer, or:
2. The SP just wasn’t able to interpret the answer, regardless, or:
3. My contact on the IDP side changed something last night, and didn’t tell me. :-)
I mention case #2 because prior to setting the NameIDPolicy to null, what I observed was this. When the SP initiated things, the response included:
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://signin-stage.mycompany.example.com:443/fed/idp"
SPNameQualifier=“jkapp-stage"
>id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-</saml:NameID>
However, when the IDP initiated things, it included:
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">klassa</saml:NameID>
So, I was assuming that it wasn’t working in the former case, because I didn’t see “klassa” in the raw message exchange — and in my original post, I said that no ’name’ was returned because the print_r in the simple login test app from the docs showed an empty array. Perhaps the information was actually encoded in that cryptic string ("id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-"), but something prevented the SP from decoding (or maybe just returning) it?
Anyway, it’s working now, so I’m in a much better place.
Thanks for your help, gentlemen!
Peter Schober
Oct 24, 2015, 12:29:21 PM10/24/15
to simple...@googlegroups.com
* John Klassa <jo...@klassa.com> [2015-10-24 15:44]:
> 1. The SP requested a name format that the IDP didn’t support, and
> so the IDP wasn’t able to give back a suitable answer
No, the SP requested a NameID the IDP did support and release. You
just thought something was weird about that due to not knowing what
transient NameIDs are (which are not really useful in SAML2.0 anyway).
> 2. The SP just wasn’t able to interpret the answer, regardless, or:
No, they're just ugly strings, that's all.
And NameIDs are not attributes which confused matters, I suppose.
> 3. My contact on the IDP side changed something last night, and didn’t tell me. :-)
That can trivially be ruled out (or confirmed) by changing the setting
I mentioned it back in SSP, and again comparing results from
SP-initiate with IDP-initiated.
> I mention case #2 because prior to setting the NameIDPolicy to null,
> what I observed was this. When the SP initiated things, the
> response included:
>
> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> NameQualifier="https://signin-stage.mycompany.example.com:443/fed/idp"
> SPNameQualifier=“jkapp-stage"
> >id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-</saml:NameID>
That's fine. (Strictly speaking the SPNameQualifier -- the name of your
SP -- is not valid, as that needs to be a URI with a valid schema but
that would need to be correct on your side and in the metadata given
to the IDP).
The value literally is "id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-" (plus the
qualifiers), all of which won't be of much help to you.
> However, when the IDP initiated things, it included:
>
> <saml:NameID
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">klassa</saml:NameID>
That does not look like an X.509 subject name to me, but whatever.
A different NameID type, either the IDP's default or configured at the
IDP to be used for your SP.
> So, I was assuming that it wasn’t working in the former case
It was always sending something, but in the "not working" case the IDP
was sending what your SP requested. And your SP requested a tranisient
NameID (which is a not-so-useful default for SSP, but I have said as
much many times now).
> because I didn’t see “klassa” in the raw message exchange — and in
> my original post, I said that no ’name’ was returned because the
> print_r in the simple login test app from the docs showed an empty
> array.
From what you have written in this thread (which has very little
technical details), the IDP probably never issued any attributes,
hence my guess (which turned out to be correct) that it's the NameID
formats that are different, not the released attributes.
> Perhaps the information was actually encoded in that cryptic string
> ("id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-"), but something prevented the SP
> from decoding (or maybe just returning) it?
It's not cryptic, just long and ugly (and only valid for a short
time), and there is no decoding to perform: That's the literal value
of the identifier. Cf. the SAML specs or this page from the Shibboleth
wiki for details:
https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers
-peter
> > Background: As the proprietary request sent to the IDP is not fully
> > equivalent to the SAML-defined one
> > ...
> > As a quick test you could set
> > 'NameIDPolicy' => null,
> > in your 'saml:SP' authsource (in config/authsources.php of your SSP
> > install) and try again?.
>
> Bingo… Setting NameIDPolicy to null did the trick!
OK, so the IDP's behaviour is not so weird after all.
> > equivalent to the SAML-defined one
> > ...
> > As a quick test you could set
> > 'NameIDPolicy' => null,
> > in your 'saml:SP' authsource (in config/authsources.php of your SSP
> > install) and try again?.
>
> Bingo… Setting NameIDPolicy to null did the trick!
> 1. The SP requested a name format that the IDP didn’t support, and
> so the IDP wasn’t able to give back a suitable answer
just thought something was weird about that due to not knowing what
transient NameIDs are (which are not really useful in SAML2.0 anyway).
> 2. The SP just wasn’t able to interpret the answer, regardless, or:
And NameIDs are not attributes which confused matters, I suppose.
> 3. My contact on the IDP side changed something last night, and didn’t tell me. :-)
I mentioned it back in SSP, and again comparing results from
SP-initiate with IDP-initiated.
> I mention case #2 because prior to setting the NameIDPolicy to null,
> what I observed was this. When the SP initiated things, the
> response included:
>
> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> NameQualifier="https://signin-stage.mycompany.example.com:443/fed/idp"
> SPNameQualifier=“jkapp-stage"
> >id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-</saml:NameID>
SP -- is not valid, as that needs to be a URI with a valid schema but
that would need to be correct on your side and in the metadata given
to the IDP).
The value literally is "id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-" (plus the
qualifiers), all of which won't be of much help to you.
> However, when the IDP initiated things, it included:
>
> <saml:NameID
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">klassa</saml:NameID>
A different NameID type, either the IDP's default or configured at the
IDP to be used for your SP.
> So, I was assuming that it wasn’t working in the former case
was sending what your SP requested. And your SP requested a tranisient
NameID (which is a not-so-useful default for SSP, but I have said as
much many times now).
> because I didn’t see “klassa” in the raw message exchange — and in
> my original post, I said that no ’name’ was returned because the
> print_r in the simple login test app from the docs showed an empty
> array.
technical details), the IDP probably never issued any attributes,
hence my guess (which turned out to be correct) that it's the NameID
formats that are different, not the released attributes.
> Perhaps the information was actually encoded in that cryptic string
> ("id-0qzuXn0Itq-xwVRvRXMQN-1pwpY-"), but something prevented the SP
> from decoding (or maybe just returning) it?
time), and there is no decoding to perform: That's the literal value
of the identifier. Cf. the SAML specs or this page from the Shibboleth
wiki for details:
https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers
-peter
Reply all
Reply to author
Forward
0 new messages