Accessing SAMLResponse assertion data without authentication

[cludwig]

We're configured as an SP, and have a partner using PingFederated as
an IdP. We'd like to let them POST their assertions to us and trust
that authentication has happened on their side, read some attributes
from SAMLResponse (including a "memberID" that they're sending us) and
then create new users in our custom app on our side.

We're stymied at the moment because we seem to be able to access the
attribute data in SAMLResponse after the user's been authenticated
using $as->requireAuth(). We'd like to get at the data in SAMLResponse
without having an authenticated user so that we can decide whether to
create a new user on our side or not.

Essentially we trust the IdP to always send us users authenticated on
their side (without another round-trip to them for authentication),
and we'll be using their (minimal) attributes to then create a user on
our side.

Any thoughts on how to get at the SAMLResponseData either:
1. without authenticating, or
2. using an authentication method that we control and always
succeeds without actually need to round-trip to the IdP?

Thanks!

[Olav Morken]

Actually, having received a valid SAMLResponse counts as authenticated
from the simpleSAMLphp SPs point of view. It does not have a concept of
user database or anything like that. (That is the applications job :)

What you are describing is IdP initiated authentication / IdP first
flow. This is where the IdP sends an unsolicited authentication
response to the SP. (Unsolicited since the SP hasn't sent an
authentication request to the IdP first.)

This is supported by simpleSAMLphp, and the requireAuth()-function
should just return in that case. So, my guess is that something else
isn't working correctly for you. Have you checked the simpleSAMLphp
log? (By default logged to syslog, so you can find it in
/var/log/syslog , /var/log/messages or something like that. You may
also want to increase the logging level in config/config.php .

Best regards,
Olav Morken
UNINETT / Feide

[cludwig]

Thank you very much, Olav.

We tried to add the entity id info in the authsources SP on our end
and also added a relayState parameter to take the user to a test page
showing all attributes using getAttributes().

In the metadata file on the SP side (saml20-idp-remote), we added

'SingleSignOnService' => 'http://testmachine/simplesaml/saml2/idp/
SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/
sp/saml2-acs.php/default-sp',

*Note that we have added the spentityid variable to have it working as
IdP initiated response.

Even doing so, the system still attempts to redirect to the IdP to
enter credentials on the IdP site in order to be transferred to the
SP.

We see this in the log:
Jan 18 14:35:39 simplesamlphp NOTICE [af7e44ebd6] Session: 'default-
sp' not valid because we are not authenticated.
Jan 18 14:35:39 simplesamlphp NOTICE [af7e44ebd6] Saved state:
'_2e556991f2385b6780019808a033341eff20a0c106'
Jan 18 14:35:39 simplesamlphp NOTICE [af7e44ebd6] Sending SAML 2
AuthnRequest to 'partner.com:saml2.0'

Two questions:

1. Is it possible to have IdP initiated first setup where user does
not have to enter credentials (username/password) on the IdP after the
SAMLResponse has been sent to SP?

2. In case of an IdP-first response, the test would be to POST
SAMLResponse directly access the above link right? Or would there be
any other way of testing an IdP-first response?

Thanks!

[Olav Morken]

On Wed, Jan 18, 2012 at 14:53:33 -0800, cludwig wrote:
> Thank you very much, Olav.
>
> We tried to add the entity id info in the authsources SP on our end
> and also added a relayState parameter to take the user to a test page
> showing all attributes using getAttributes().
>
> In the metadata file on the SP side (saml20-idp-remote), we added
>
> 'SingleSignOnService' => 'http://testmachine/simplesaml/saml2/idp/
> SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/
> sp/saml2-acs.php/default-sp',

This does not really make sense - you cannot add an IdP-initiated
authentication URL here. Also, wasn't your IdP using PingFederated?
That URL is for a simpleSAMLphp IdP.

Also, your SP's entityID is unlikely to be
"http://testing.gf.com/saml/module.php/saml/sp/saml2-acs.php/default-sp".
That looks like your SPs AssertionConsumerService endpoint. (Of course,
nothing prevents you from reusing the same URI as an entityID, but it
will lead to confusion for everyone that looks at your SP
configuration.)

> *Note that we have added the spentityid variable to have it working as
> IdP initiated response.

If the IdP does not support SP initiated authentication, there should
not be a SingleSignOnService endpoint for it. The SingleSignOnService
endpoint is only used for SP initiated authentication.

> Even doing so, the system still attempts to redirect to the IdP to
> enter credentials on the IdP site in order to be transferred to the
> SP.
>
> We see this in the log:
> Jan 18 14:35:39 simplesamlphp NOTICE [af7e44ebd6] Session: 'default-
> sp' not valid because we are not authenticated.
> Jan 18 14:35:39 simplesamlphp NOTICE [af7e44ebd6] Saved state:
> '_2e556991f2385b6780019808a033341eff20a0c106'
> Jan 18 14:35:39 simplesamlphp NOTICE [af7e44ebd6] Sending SAML 2
> AuthnRequest to 'partner.com:saml2.0'

I do not see any log messages from when the IdP sent the unsolicited
resposne to your SP. Are you sure that it was sent?

> Two questions:
>
> 1. Is it possible to have IdP initiated first setup where user does
> not have to enter credentials (username/password) on the IdP after the
> SAMLResponse has been sent to SP?

Yes, that is the way it normally works.

> 2. In case of an IdP-first response, the test would be to POST
> SAMLResponse directly access the above link right? Or would there be
> any other way of testing an IdP-first response?

What link? The IdP must send the unsolicited response message to your
SPs AssertionConsumerService endpoint. Typically that is configured at
the IdP.

[cludwig]

The IdP from the client will be PingFederated. To test the scenario of
using IdP intiated-first flow, we are using a test machine.
We have tested the SP-first initiated login which makes the user be
redirected to the IdP where they are asked to enter credentials and
their attributes are hence seen on the SP side.

Here are the detailed metadata which we are using:

Test machine - IdP

testing.gf.com - SP

Goal is to make IdP initiated flow work.

IdP side:

saml20-sp-remote.php

$metadata['http://testing.gf.com/saml/module.php/saml/sp/metadata.php/
default-sp'] = array(
    'AssertionConsumerService' => 'http://testing.gf.com/saml/
module.php/saml/sp/saml2-acs.php/default-sp',
    'SingleLogoutService'      => 'http://testing.gf.com/saml/
module.php/saml/sp/saml2-logout.php/default-sp',
);

saml20-idp-hosted.php

$metadata['__DYNAMIC:1__'] = array(
 /*
  * The hostname of the server (VHOST) that will use this SAML entity.
  *
  * Can be '__DEFAULT__', to use this entry by default.
  */
 'host' => '__DEFAULT__',
 /* X.509 key and certificate. Relative to the cert directory. */
 'privatekey' => 'server.pem',
 'certificate' => 'server.crt',
 /*
  * Authentication source to use. Must be one that is configured in
  * 'config/authsources.php'.
  */
 'auth' => 'example-userpass',
 /* Uncomment the following to use the uri NameFormat on attributes.
*/
 /*
 'AttributeNameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-
format:uri',
 'authproc' => array(
  // Convert LDAP names to oids.
  100 => array('class' => 'core:AttributeMap', 'name2oid'),
 ),
 */
);

On the SP side, we have set up the testing.gf.com machine:

authsources.php

$config = array(
    'default-sp' => array(
     'saml:SP',
  'privatekey'=>'testingPrivateKey.pfx',
  'certificate'=>'testingCert.cer',

  'idp' => 'http://testmachine/simplesaml/saml2/idp/metadata.php',

  'RelayState' => 'http://testing.gf.com/saml/mylogin.php',
  'entityID' => 'http://testing.gf.com/saml/module.php/saml/sp/
metadata.php/default-sp'

 ),
);

saml20-idp-remote.php

 $metadata['http://testmachine/simplesaml/saml2/idp/metadata.php'] =
array (
  'metadata-set' => 'saml20-idp-remote',
  'entityid' => 'http://testmachine/simplesaml/saml2/idp/
metadata.php',
  'SingleSignOnService' => 'http://testmachine/simplesaml/saml2/idp/
SSOService.php',
  'SingleLogoutService' => 'http://testmachine/simplesaml/saml2/idp/
SingleLogoutService.php',
  'certData' =>
'MIICgTCCAeoCCQCbOlrWDdX7FTANBgkqhkiG9w0BAQUFADCBhDELMAkGA1UEBhMCTk8xGDAWBgNVBAgTD0FuZHJlYXMgU29sYmVyZzEMMAoGA1UEBxMDRm9vMRAwDgYDVQQKEwdVTklORVRUMRgwFgYDVQQDEw9mZWlkZS5lcmxhbmcubm8xITAfBgkqhkiG9w0BCQEWEmFuZHJlYXNAdW5pbmV0dC5ubzAeFw0wNzA2MTUxMjAxMzVaFw0wNzA4MTQxMjAxMzVaMIGEMQswCQYDVQQGEwJOTzEYMBYGA1UECBMPQW5kcmVhcyBTb2xiZXJnMQwwCgYDVQQHEwNGb28xEDAOBgNVBAoTB1VOSU5FVFQxGDAWBgNVBAMTD2ZlaWRlLmVybGFuZy5ubzEhMB8GCSqGSIb3DQEJARYSYW5kcmVhc0B1bmluZXR0Lm5vMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDivbhR7P516x/
S3BqKxupQe0LONoliupiBOesCO3SHbDrl3+q9IbfnfmE04rNuMcPsIxB161TdDpIesLCn7c8aPHISKOtPlAeTZSnb8QAu7aRjZq3+PbrP5uW3TcfCGPtKTytHOge/
OlJbo078dVhXQ14d1EDwXJW1rRXuUt4C8QIDAQABMA0GCSqGSIb3DQEBBQUAA4GBACDVfp86HObqY
+e8BUoWQ9+VMQx1ASDohBjwOsg2WykUqRXF+dLfcUH9dWR63CtZIKFDbStNomPnQz7nbK
+onygwBspVEbnHuUihZq3ZUdmumQqCw4Uvs/1Uvq3orOo/
WJVhTyvLgFVK2QarQ4/67OZfHd7R+POBXhophSMv1ZOo',
  'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-
format:transient',
);

We have two simple pages

mylogin.php (a page on the SP side which displays the user input
attributes) -- This will be the relayState page which shows the
attributes are being decoded after authentication:

<?php
require_once('../lib/_autoload.php');
$as = new SimpleSAML_Auth_Simple('default-sp');
$as->requireAuth();

$attributes = $as->getAttributes();
echo '<pre>';
print_r($attributes);
echo'</pre>';

To make it work with IdP first initiated, we have a simple form which
will pass the SAMLResponse to the SP (the spentityID is present)

<?php
echo '<form action="http://testmachine/simplesaml/saml2/idp/
SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/
sp/metadata.php/default-sp" method="post">';
echo '<br />SAML Response<textarea rows="30" cols="50"
name="SAMLResponse"></textarea>';
echo '<br /><input type="submit" value="Please Post via IdP." />';
echo '</form>';

As mentioned before, the SP first works perfectly. Could you take a
look at and let us know what/where is the issue for IdP first not
being authenticated?

Is our way of testing by having a simple form post to the page:

http://testmachine/simplesaml/saml2/idp/SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/sp/metadata.php/default-sp
valid?

Any help would be greatly appreciated.

Thanks!

[Olav Morken]

On Thu, Jan 19, 2012 at 14:30:03 -0800, cludwig wrote:
> The IdP from the client will be PingFederated. To test the scenario of
> using IdP intiated-first flow, we are using a test machine.
> We have tested the SP-first initiated login which makes the user be
> redirected to the IdP where they are asked to enter credentials and
> their attributes are hence seen on the SP side.
>
> Here are the detailed metadata which we are using:

[...]

> To make it work with IdP first initiated, we have a simple form which
> will pass the SAMLResponse to the SP (the spentityID is present)
>
> <?php
> echo '<form action="http://testmachine/simplesaml/saml2/idp/
> SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/
> sp/metadata.php/default-sp" method="post">';
> echo '<br />SAML Response<textarea rows="30" cols="50"
> name="SAMLResponse"></textarea>';
> echo '<br /><input type="submit" value="Please Post via IdP." />';
> echo '</form>';
>
> As mentioned before, the SP first works perfectly. Could you take a
> look at and let us know what/where is the issue for IdP first not
> being authenticated?
>
> Is our way of testing by having a simple form post to the page:
>
> http://testmachine/simplesaml/saml2/idp/SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/sp/metadata.php/default-sp
> valid?

This will not work. The IdP does not accept a SAML 2.0 response.
Instead, the IdP generates a SAML 2.0 response. Thus sending a SAML 2.0
response to the IdPs SingleSignOnService endpoint does not really make
sense.

Instead, to test IdP initiated SSO, trigger the SSO endpoint with a
normal request:

http://testmachine/simplesaml/saml2/idp/SSOService.php?spentityid=http://testing.gf.com/saml/module.php/saml/sp/metadata.php/default-sp

Yes, you will be asked for a username and password, but that is because
the IdP needs to authenticate the user somehow. If you (for testing
purposes) do not want to see a login form, change the authentication
source to something like exampleauth:Static.