How to implement simpleSAMLphp using the HTTP-POST binding
barbutti47
I'm new to simpleSAMLphp and I'm having some trouble figuring out how
use simpleSAMLphp as an SP using the HTTP-POST binding.
I couldn't find any info in the official documentation either (for
example, while this helps a bit, it's not really enough for a newbie
like me: http://simplesamlphp.org/docs/1.7/simplesamlphp-sp#section_6)
Is there any code examples available online on how to do this?
Thanks in advance for the help.
Peter Schober
That very URL has code examples, there is nothing more to it, once you
have configured (as per the documentation) the SP and IDP correctly.
You don't programm the data exchange yourself, you use SimpleSAMLphp's
API to handle all that for you.
If you don't want that, feel free to try to implement the necessary
profiles yourself.
-peter
barbutti47
I'm having trouble finding this online.
Maybe I'm missing the point of the HTTP-POST binding. Shouldn't it
allow me to host the login form in the SP, and authenticate to the IdP
using a POST call that is transparent to the end user?
On Mar 15, 2:44 pm, Peter Schober <peter.scho...@univie.ac.at> wrote:
> * barbutti47 <barbu...@gmail.com> [2011-03-15 16:09]:
Tom Scavo
>
> Maybe I'm missing the point of the HTTP-POST binding. Shouldn't it
> allow me to host the login form in the SP, and authenticate to the IdP
> using a POST call that is transparent to the end user?
Most definitely not. That is not how SAML Web Browser SSO works. You
should read the SAML Tech Overview before continuing:
http://wiki.oasis-open.org/security/Saml2TechOverview
Bottom line: use HTTP-Redirect at the SP. It's simpler and is usually
the Right Thing To Do.
Tom
Tom Scavo
> I'm a real newbie to SAML
That's okay, I was a newbie at one time :-)
> I've successfully set up a simpleSAMLphp as my SP, but I'm getting the
> following error back from the IdP:
>
> "sspmod_saml_Error: Responder/InvalidNameIDPolicy: NameID Format not
> supported: urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>
> This happens after I'm successfully logged in from the IdP site, right
> when I'm redirected back to simpleSAMLphp's page.
>
> Any ideas on what could be causing this, or tips on how to investigate
> this better?
> Could this be a problem in the IdP itself?
So you don't control the IdP, right? Well, the IdP wants some other
NameID, that's clear as day. Does the IdP say (in its metadata) what
NameIDs it supports? If not, you'll have to determine that out of band
and configure your SP accordingly.
Tom
Tom Scavo
>
> I switched the NameIDFormat in my SP configuration and it worked.
To what? (I'm just curious :)
> The weird thing is that the IdP metadata says it supports
> "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"; I guess they're
> broadcasting that wrong.
Well, no, the IdP can say it supports a lot of things, but in the end
it depends on what it receives in the AuthnRequest and a host of other
things. Does the IdP call out other NameID formats in its metadata?
I don't know how SSP treats NameIDFormat in metadata on both ends. Can
someone say a few words about that?
Thanks,
Tom
barbutti47
On Mar 15, 9:08 pm, Tom Scavo <trsc...@gmail.com> wrote:
>
> > I switched the NameIDFormat in my SP configuration and it worked.
>
> To what? (I'm just curious :)
to a website and to other systems used by real state agencies.
>
> > The weird thing is that the IdP metadata says it supports
> > "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"; I guess they're
> > broadcasting that wrong.
>
> Well, no, the IdP can say it supports a lot of things, but in the end
> it depends on what it receives in the AuthnRequest and a host of other
> things. Does the IdP call out other NameID formats in its metadata?
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</
NameIDFormat>
<NameIDFormat>urn:clareity:safemls:nameid-format:loginid</
NameIDFormat>
<NameIDFormat>com.clareity.safemls:nameid-format:loginid</
NameIDFormat>
I assumed they were all the accepted ones, but turns out that isn't
the case.
Olav Morken
> I don't know how SSP treats NameIDFormat in metadata on both ends. Can
> someone say a few words about that?
If I recall correctly:
- The SP ignores it and requests whatever format is in its
configuration.
- The IdP uses the first entry as a default format if the SP doesn't
request a specific NameID format.
Regards,
Olav Morken
UNINETT / Feide
Tom Scavo
>
> On Mar 15, 9:08 pm, Tom Scavo <trsc...@gmail.com> wrote:
>> On Tue, Mar 15, 2011 at 8:00 PM, barbutti47 <barbu...@gmail.com> wrote:
>>
>> > I switched the NameIDFormat in my SP configuration and it worked.
>>
>> To what? (I'm just curious :)
>
> It's for a real estate system, it connects property listing database
> to a website and to other systems used by real state agencies.
No, I mean how did you change your SP configuration? What did you
change NameIDFormat to so it worked? After you changed your config,
did you supply the IdP with new metadata?
>> Does the IdP call out other NameID formats in its metadata?
>
> Yes, the IdP metadata contains 4 different NameIDs. Here:
>
> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</
> NameIDFormat>
> <NameIDFormat>urn:clareity:safemls:nameid-format:loginid</
> NameIDFormat>
> <NameIDFormat>com.clareity.safemls:nameid-format:loginid</
> NameIDFormat>
So which one of these did you end up using?
Tom
barbutti47
In my authsources.php, when configuring the SP, I've explicitly
specified which NameID to use with the following array item:
'NameIDFormat' => 'urn:clareity:safemls:nameid-format:loginid'
It was a trial and error process, testing each of the NameIDFormats
provided by the IdP metadata and seeing which one worked.
On Mar 16, 9:56 am, Tom Scavo <trsc...@gmail.com> wrote:
Paul Hethmon
any of the listed formats. However, I always send back my format which is
where I think you have to configure SS to accept that one in the SAML
response.
If you don't configure SS to expect the format returned, then it doesn't
like it.
thanks,
Paul
>--
>You received this message because you are subscribed to the Google Groups
>"simpleSAMLphp" group.
>To post to this group, send email to simple...@googlegroups.com.
>To unsubscribe from this group, send email to
>simplesamlph...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/simplesamlphp?hl=en.
>
Tom Scavo
>
> Yes, the IdP metadata contains 4 different NameIDs. Here:
>
> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</
> NameIDFormat>
> <NameIDFormat>urn:clareity:safemls:nameid-format:loginid</
> NameIDFormat>
> <NameIDFormat>com.clareity.safemls:nameid-format:loginid</
> NameIDFormat>
>
> I assumed they were all the accepted ones, but turns out that isn't
> the case.
I was wrong before. When you ask for a transient identifier, you
should receive a transient identifier, not because the transient
format appears in metadata, but because of the following requirement
in SAML V2.0 Core:
"When a Format defined in Section 8.3 other than
urn:oasis:names:tc:SAML:1.1:nameid- format:unspecified or
urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted is used, then if
the identity provider returns any assertions: the Format value of the
<NameID> within the <Subject> of any <Assertion> MUST be identical to
the Format value supplied in the <NameIDPolicy>."
If the IdP can't (or won't) honor the request, it must return an error
(which it apparently did it your case).
On the SP side, if you ask for a particular format, you should expect
to receive it, but of course you can't guarantee that an IdP will
behave according to the spec. So the SP should have some way to check
make sure it receives a NameID of a particular format.
Tom
Tom Scavo
<paul.h...@clareitysecurity.com> wrote:
> To chime in here since it's my IdP. I'm running Shibboleth and will accept
> any of the listed formats. However, I always send back my format which is
> where I think you have to configure SS to accept that one in the SAML
> response.
If that were true, it would be a bug in your IdP implementation, but
it's not true since the error message posted earlier in this thread
was an IdP error message.
> If you don't configure SS to expect the format returned, then it doesn't
> like it.
That doesn't appear to be what's going on here. AFAICT, the SP asked
for transient and the IdP returned an error. Then the SP asked for the
custom NameID and received it. If all that's true, you should probably
adjust the IdP metadata to reflect its actual policy.
Tom
barbutti47
"urn:oasis:names:tc:SAML:2.0:nameid-format:transient"; I guess they're
broadcasting that wrong.
Cheers
Brian
On Mar 15, 8:57 pm, Tom Scavo <trsc...@gmail.com> wrote:
barbutti47
I've read on that tech overview and everything makes more sense now.
I'm a real newbie to SAML, so things are a bit blurry yet.
I've successfully set up a simpleSAMLphp as my SP, but I'm getting the
following error back from the IdP:
"sspmod_saml_Error: Responder/InvalidNameIDPolicy: NameID Format not
supported: urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
This happens after I'm successfully logged in from the IdP site, right
when I'm redirected back to simpleSAMLphp's page.
Any ideas on what could be causing this, or tips on how to investigate
this better?
Could this be a problem in the IdP itself?
On Mar 15, 4:42 pm, Tom Scavo <trsc...@gmail.com> wrote: