POST redirect

[Azriel Fasten]

Hi all, I just started messing with the library, mighty impressed.

I was wondering if there was any way to avoid the HTTP POST/redirect when authentication completes, say by using curl (to send the actual data to the sp, with only a token being passed in a GET) or something to that effect.

--

Azriel Fasten

[Peter Schober]

* Azriel Fasten <azriel...@gmail.com> [2010-08-30 15:49]:

> I was wondering if there was any way to avoid the HTTP POST/redirect when
> authentication completes, say by using curl (to send the actual data to the
> sp, with only a token being passed in a GET) or something to that effect.

If you're suggesting alternative SAML protocol bindings, the OASIS
security services technical commitee is the right place for that.
-peter

[Olav Morken]

My guess is that you are looking for alternate protocol bindings, in
which case you may want to look at the HTTP-Artifact binding. It isn't
exactly what you want, but probably close enough.

When the IdP sends the response:

1. Save the response locally.
2. Redirect the users browser back to the SP using a normal redirect,
include a token identifying the response message and where it can be
retrieved.
3. The SP retrieves the response from the IdP.

Check out:
- http://simplesamlphp.org/docs/1.6/simplesamlphp-artifact-sp
- http://simplesamlphp.org/docs/1.6/simplesamlphp-artifact-idp

Regards,
Olav Morken
UNINETT / Feide

[Azriel Fasten]

This is exactly what I wanted. Thanks a lot. I also noticed how an SQL store was recently implemented ;).

However, when I setup my configuration to use HTTP-artifact binding following those instructions, I get the following error on the Idp (asterisks inserted):

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

Backtrace:
1 /home/sgrwiki/simplesaml_idp/www/_include.php:34 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: Exception: saml20-sp-remote/'http://sgrwiki.com/auth/module.php/saml/sp/metadata.php/default-sp'['AssertionConsumerService']:Could not find a supported AssertionConsumerService endpoint.
Backtrace:
2 /home/sgrwiki/simplesaml_idp/lib/SimpleSAML/Configuration.php:976 (SimpleSAML_Configuration::getDefaultEndpoint)
1 /home/sgrwiki/simplesaml_idp/modules/saml/lib/IdP/SAML2.php:250 (sspmod_saml_IdP_SAML2::receiveAuthnRequest)
0 /home/sgrwiki/simplesaml_idp/www/saml2/idp/SSOService.php:19 (N/A)

--

Azriel Fasten

[Olav Morken]

[...]

> saml20-sp-remote/'http://sgrwiki.com/auth/module.php/saml/sp/metadata.php/default-sp'['AssertionConsumerService']:Could
> not find a supported AssertionConsumerService endpoint.

[...]

When using the HTTP-Artifact binding, you need to add a more complex
AssertionConsumerService URL in the metadata for the SP. Take a look
at:

http://simplesamlphp.org/docs/1.6/simplesamlphp-metadata-endpoints

(Or just use the metadata parser in simpleSAMLphp to parse the XML
metadata.)

You will probably also need to add the ArtifactResolutionService to the
IdP metadata in saml20-idp-remote.

[Azriel Fasten]

On Mon, Sep 6, 2010 at 2:29 AM, Olav Morken <olav....@uninett.no> wrote:

When using the HTTP-Artifact binding, you need to add a more complex
AssertionConsumerService URL in the metadata for the SP. Take a look
at:

   http://simplesamlphp.org/docs/1.6/simplesamlphp-metadata-endpoints

(Or just use the metadata parser in simpleSAMLphp to parse the XML
metadata.)

You will probably also need to add the ArtifactResolutionService to the
IdP metadata in saml20-idp-remote.

I definately needed to use the xml generator ;). I used trunk in order to take advantage of the SQL store, however I believe I found a bug. In /lib/SAML2/HTTPArtifact.php, at apprimately line 99 the class sspmod_saml2_Message is used. It appears you guys are migrating to removing dual saml classes or something to that effect. The actual class is now sspmod_saml_Message.

Another bug I haven't yet looked into but kludged in the meantime in /modules/saml/www/sp/saml2-acs.php:

At approximately line 58: $store = SimpleSAML_Store::getInstance();

store is set as bool(false), not null nore an object. 

--

Azriel Fasten

[Olav Morken]

On Mon, Sep 06, 2010 at 10:44:38 -0400, Azriel Fasten wrote:
> On Mon, Sep 6, 2010 at 2:29 AM, Olav Morken <olav....@uninett.no> wrote:
> >
> >
> > When using the HTTP-Artifact binding, you need to add a more complex
> > AssertionConsumerService URL in the metadata for the SP. Take a look
> > at:
> >
> > http://simplesamlphp.org/docs/1.6/simplesamlphp-metadata-endpoints
> >
> > (Or just use the metadata parser in simpleSAMLphp to parse the XML
> > metadata.)
> >
> > You will probably also need to add the ArtifactResolutionService to the
> > IdP metadata in saml20-idp-remote.
>
>
> I definately needed to use the xml generator ;). I used trunk in order to
> take advantage of the SQL store, however I believe I found a bug. In
> /lib/SAML2/HTTPArtifact.php, at apprimately line 99 the class

> sspmod_saml*2*_Message

> is used. It appears you guys are migrating to removing dual saml classes or
> something to that effect. The actual class is now sspmod_saml_Message.

Is it possible that this file hasn't been updated to the latest
revision in your tree? That file was changed at the same time as all
other files that contained sspmod_saml2_Message (i.e. r2372).

> Another bug I haven't yet looked into but kludged in the meantime in
> /modules/saml/www/sp/saml2-acs.php:
> At approximately line 58: $store = SimpleSAML_Store::getInstance();
> store is set as bool(false), not null nore an object.

Yes, that is a bug, the check should be against FALSE, not NULL. I have
committed a fix. The FALSE value indicates that you are still using the
builtin session handler in PHP.

You need to set 'store.type' to 'sql' in config/config.php to enable
storing of data to SQL.

[Azriel Fasten]

On Tue, Sep 7, 2010 at 1:47 AM, Olav Morken <olav....@uninett.no> wrote:

On Mon, Sep 06, 2010 at 10:44:38 -0400, Azriel Fasten wrote:
> On Mon, Sep 6, 2010 at 2:29 AM, Olav Morken <olav....@uninett.no> wrote:

Is it possible that this file hasn't been updated to the latest
revision in your tree? That file was changed at the same time as all
other files that contained sspmod_saml2_Message (i.e. r2372).

Indeed, I must have gotten some of the tree messed up.

 

Yes, that is a bug, the check should be against FALSE, not NULL. I have
committed a fix. The FALSE value indicates that you are still using the
builtin session handler in PHP.

You need to set 'store.type' to 'sql' in config/config.php to enable
storing of data to SQL.

Yes, I noticed and fixed this myself. As for the SQL, this is in the SP, which I didn't really want to bother with SQL. However, if it prevents a possible attack I will consider it if I have the time. I am wondering, why is it that phpsession cannot implement the Store class? I can easily implement that class in terms of the session variable. Is it because the session isn't stored between users, and thus different users will have different sessions? 

[Olav Morken]

On Tue, Sep 07, 2010 at 07:24:36 -0400, Azriel Fasten wrote:
> > Yes, that is a bug, the check should be against FALSE, not NULL. I have
> > committed a fix. The FALSE value indicates that you are still using the
> > builtin session handler in PHP.
> >
> > You need to set 'store.type' to 'sql' in config/config.php to enable
> > storing of data to SQL.
>
>
> Yes, I noticed and fixed this myself. As for the SQL, this is in the SP,
> which I didn't really want to bother with SQL. However, if it prevents a
> possible attack I will consider it if I have the time. I am wondering, why
> is it that phpsession cannot implement the Store class? I can easily
> implement that class in terms of the session variable. Is it because the
> session isn't stored between users, and thus different users will have
> different sessions?

Yes, that is exactly the reason. When the SP receives a response with
the HTTP-Artifact binding, it sends a SOAP-request to the IdP. This
request doesn't come with the session cookie for the user, so we don't
have the users session available (without doing some rather ugly hacks).

Note that this only affects the IdP. The SP can use the PHP session
handler, since it doesn't need to save anything outside of the session
when receiving the HTTP-Artifact message.