SAML 2.0 as SP => SAML 1.1 as IdP

[Sean Willess]

All,

I have been able to configure my staging server as the SP and successfully send AuthRequests to my remote IdP. The AuthRequest I send over is in SAML 2.0, but then the IdP response is in SAML 1.1 (without the prefixes "saml:" or "samlp:" in the XML tags). I have tried to bridge between protocols following the instructions here, but I'm not sure if this is the way to go since I'm not sending SAML 1.1 to the IdP. I also get this error in my syslog: Session: 'test-development' not valid because we are not authenticated. What do I need to configure on my SP to be able to receive and read the SAML 1.1 response?

Thanks,

Sean

[Tom Scavo]

On Mon, Jul 7, 2014 at 3:09 PM, Sean Willess <swill...@gmail.com> wrote:
>
> I have been able to configure my staging server as the SP and successfully
> send AuthRequests to my remote IdP. The AuthRequest I send over is in SAML
> 2.0, but then the IdP response is in SAML 1.1

That's a bug.

> (without the prefixes "saml:" or "samlp:" in the XML tags).

The XML namespace prefixes have nothing to do with SAML1 vs. SAML2.

> I have tried to bridge between protocols
> following the instructions here

That's an ancient version of the documentation. What version of SSP is
your SP running? Is your IdP running SSP or something else?

> but I'm not sure if this is the way to go
> since I'm not sending SAML 1.1 to the IdP.

If the IdP doesn't support SAML2, then you obviously should not send
them a SAML2 AuthnRequest.

> I also get this error in my
> syslog: Session: 'test-development' not valid because we are not
> authenticated. What do I need to configure on my SP to be able to receive
> and read the SAML 1.1 response?

The SAML1 standard doesn't support SP-initiated flows so the
Shibboleth Project invented a SAML1 SP-first protocol many moons ago.
It is called Shibboleth AuthnRequest for SAML1 and SSP supports it, I
believe. Now the question is: Does your IdP partner support it?

Tom

[Sean Willess]

Thanks for the quick response. I'm new to SAML, so please forgive my noob-ness. So I actually was incorrect in stating that the IdP is sending a SAML 1.1 response; it actually is 2.0. I was looking at the XML tags prefixes and assumed that was the issue. 

So why wouldn't my SP recognize the IdP's SAML response? I was able to get simpleSAMLphp to recognize the SAML responses when testing my local SP with OpenIDP. But once I moved everything to staging and configured for our IdP partner, our simpleSAMLphp is no longer recognizing the SAML response and I started coming across the session error.

I have configured my IdP metadata "http://development.idp.com/adfs/services/trust" in saml20-idp-remote.php, and I point to this in my authsources.php :

 'source-development' => array(

                'saml:SP',

                'privatekey' => 'saml.pem',

                'certificate' => 'saml.crt',

                'redirect.sign' => TRUE,

                'entityID' => 'https://staging.saml.com/saml_login',

                'idp' => 'http://development.idp.com/adfs/services/trust',

                'ForceAuthn' => false,

                'IsPassive' => false,

                'AssertionConsumerService' => 'https://development.idp.com/assertion.aspx',

                'NameIDPolicy' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',

                'signature.algorithm' => 'http://www.w3.org/2000/09/xmldsig#rsa-sha1',

        ),

Let me know if you need any more information from me. Thanks in advance.

[Nate Klingenstein]

Sean,

It appears to me as if the XML "tag prefix"(should be called a namespace) may be hardwired into simpleSAMLphp when it probably should not be.  I don't know which of these is relevant code being executed, if any, but from the 1.12.0 distro:

lib/SimpleSAML/Utilities.php

 776                                 '@saml2' => 'urn:oasis:names:tc:SAML:2.0:assertion',

 777                                 '@saml2p' => 'urn:oasis:names:tc:SAML:2.0:protocol',

lib/SimpleSAML/XML/Parser.php

 19                 $this->simplexml->registerXPathNamespace('saml2',     'urn:oasis:names:tc:SAML:2.0:assertion');

 20                 $this->simplexml->registerXPathNamespace('saml2meta', 'urn:oasis:names:tc:SAML:2.0:metadata');

 21                 $this->simplexml->registerXPathNamespace('ds',        'http://www.w3.org/2000/09/xmldsig#');

If I were you, I'd wait for the developers to chime in before spending more time on this problem.

Hope this helps,

Nate.

On Jul 7, 2014, at 3:22 PM, Sean Willess <swill...@gmail.com>

 wrote:

--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, 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.

[Peter Schober]

* Sean Willess <swill...@gmail.com> [2014-07-07 23:23]:

> I have configured my IdP metadata
> "http://development.idp.com/adfs/services/trust" in saml20-idp-remote.php,
> and I point to this in my authsources.php :
>
> 'source-development' => array(
> 'saml:SP',
> 'privatekey' => 'saml.pem',
> 'certificate' => 'saml.crt',
> 'redirect.sign' => TRUE,
> 'entityID' => 'https://staging.saml.com/saml_login',
> 'idp' => 'http://development.idp.com/adfs/services/trust',
> 'ForceAuthn' => false,
> 'IsPassive' => false,
> 'AssertionConsumerService' =>
> 'https://development.idp.com/assertion.aspx',
> 'NameIDPolicy' =>
> 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
> 'signature.algorithm' =>
> 'http://www.w3.org/2000/09/xmldsig#rsa-sha1',
> ),

Where did you get all the parameters from? E.g. I don't see an
'AssertionConsumerService' parameter documented for the auth source of
a saml:SP, https://simplesamlphp.org/docs/stable/saml:sp
Even if it existed you're pointing to the IDP, but an IDP does not
consume assertions, it issues them.

* Nate Klingenstein <n...@internet2.edu> [2014-07-07 23:38]:

> It appears to me as if the XML "tag prefix"(should be called a
> namespace) may be hardwired into simpleSAMLphp when it probably
> should not be. I don't know which of these is relevant code being
> executed, if any, but from the 1.12.0 distro:

[...]

> If I were you, I'd wait for the developers to chime in before
> spending more time on this problem.

If SimpleSAMLphp did not work with a MS-ADFS SAML2.0 IDP (which this
clearly is) I guess we would have noticed by now?
-peter

[Bjorn Rohde Jensen]

<snip>

>
> If SimpleSAMLphp did not work with a MS-ADFS SAML2.0 IDP (which this
> clearly is) I guess we would have noticed by now?

We have a simplesamlphp 1.12.0 sp working with a windows 7 ADFS idp
without any problems at work.

I performed the metadata exchange by downloading the ADFS idp metadata
from its metadata url and used the converter in simplesamlphp. The ADFS
was able to import the simplesamlphp sp metadata from an url with only a
few warning.

For some reason, the ADFS didnt get the hash function right, so i had to
set that myself. The only tricky bit was getting the ADFS idp to use
transient NameId's by adding custom claim rules, but you dont seem to
want that.

Basically this should just work out of the box with very minor tweaks.

Yours sincerely,

Bjørn

[Sean Willess]

All,

Thank you all for contributing to this topic. After working with the IdP side to get both sides configured correctly, my SP is finally receive the SAML response (can see it being echoed in syslog), but I'm coming across this error: Validation of received messages enabled, but no signature found on message. I am seeing the Signature field within the SAML response, but it seems like my simpleSAMLphp isn't recognizing this. Do I have to do any other configurations to get this working?

Thanks all for your help,

Sean