Passing User Details from authpage to auth source

[Jason Judge]

I have written an authentication page and an auth source, based
loosely on the exampleauth. It works fine so far, but the authpage is
in the SSP module. I would like to move the authpage out to a separate
CRM framework, where I can use a nicer URL, and pull in the theme of
that CMS. I suspect this may not be possible.

The authpage takes the username and password in its form, validates
them against an external system, then fetches additional user
information (email, personal name, etc) once authenticated. It then
pushes those user details into the session and returns to the resume
URL.

The resume URL will then pull those user details back out of the
session, push them into the state as "Attributes" then finish off the
authentication: SimpleSAML_Auth_Source::completeAuth($state);

The calling SP can pull out those user attributes and use them
happily, all fine and good.

Now the issue:

The authpage runs within SSP, so uses SSP's sessions. If I were to
move the authpage to a page in my external CMS, it does not have
access to that same session. The IdP and the user authentication page
just happen to be on the same domain (for now) but SSP and the CMS run
their own separate sessions that will trample over each other.

Is there any way the additional user information can be passed into
the state? The state GET parameter sent back to the resume page does
not look encrypted, so I am guessing not.

Would I need to basically find some other back-channel to pass the
details from the authentication page to the Auth/Source class to
complete the authentication process? Perhaps just write it to a
database, with the state as a key, or some part of the state as the
key?

I hope that makes sense!

Thanks.

[Olav Morken]

That is correct - the state ID is just a pointer to a data object
stored in the user's SSP session.

(Also, generally pushing data through GET parameters isn't recommended,
even if you encrypt it - you end up needing to add a lot of extra code
to prevent replay attacks and that sort of things.)

> Would I need to basically find some other back-channel to pass the
> details from the authentication page to the Auth/Source class to
> complete the authentication process? Perhaps just write it to a
> database, with the state as a key, or some part of the state as the
> key?

That is probably the easiest way to do this. Just remember to erase it
from the database afterwards to prevent it from being reused. (Using
the state ID should also prevent this, but it doesn't hurt to be safe.)

A different alternative that may work, depending on what exactly
you are doing: Display the authentication page from the CRM, but make
it POST the username and password to an URL in your SSP module. It can
then verify the user and, if everything is OK, continue the
authentication process. If the username or password is incorrect, it
can redirect the user back to the authentication page with an error
message. (Of course, this only works if the only thing you need from
the CRM is the infrastructure for page layout and such things.)

Best regards,
Olav Morken
UNINETT / Feide

[Jason Judge]

Thanks for confirming my understanding.

That last suggestion makes sense. The authpage posts to itself at
present, so there is no reason why the HTML part of it could be taken
out to a different URL and still POST to the same place. The username
and error message (if authentication fails) could be passed to the
form URL via GET, without any security issues. Thanks for that insight
- the problem just needed a second pair of eyes :-)

-- Jason

[Jason Judge]

Presumably I would also need to pass the state ID into the
authentication form page too.

Just to be clear, the state ID is just going to be a short string like
this:

_6a79aa158963b969f977c4d400ad45d7f8a1bc38ad

and that is enough to get all details of the state in the authpage and
know where to send the user to next, assuming authentication was
successful? The exampleauth seems to take the content of the returnURL
parameter and treat almost the whole of that as the stateId, even
though it contains lots of extra information such as the final return
URL, the resume URL etc. that I suspect are actually *in* the state
and so are redundant.

For example, the call to:

$stateId = SimpleSAML_Auth_State::saveState($state,
'authcustom:External');

in the Auth/Example script returns the following (with domains changed
to protect the innocent):

_13882184032ba408ba14fa3dab1af3a7497e380526:http://idp.example.net/
auth/module.php/core/as_login.php?AuthId=iema&ReturnTo=http%3A%2F
%2Fsp.example.net%2Fuser%2Fuser%2Fstate

Is that right? Is that the full state ID, or is the state ID actually
only the first bit before the ":", i.e.
"_13882184032ba408ba14fa3dab1af3a7497e380526"?

The codebase I'm working on is a few months old, so maybe I'm hitting
a bug?

-- Jason

[Jason Judge]

Yes, if I put this immediately after the state is saved in the
AuthExternal script, before it passes control to the authentication
form:

$stateId = preg_replace('/:.*/', '', $stateId);

it all still works, but with much shorter URLs. I'll checkout the
latest codebase, in case this is something that is fixed, assuming it
is not something silly I'm doing, perhaps involving an incorrect or
missing setting somewhere.

tl;dr: the stateID returned after saving the state seems to include
lots of additional parts to it, including URLs. That does not look
right to me.

-- Jason

[Olav Morken]

On Fri, Feb 03, 2012 at 06:15:36 -0800, Jason Judge wrote:
> Yes, if I put this immediately after the state is saved in the
> AuthExternal script, before it passes control to the authentication
> form:
>
> $stateId = preg_replace('/:.*/', '', $stateId);
>
> it all still works, but with much shorter URLs. I'll checkout the
> latest codebase, in case this is something that is fixed, assuming it
> is not something silly I'm doing, perhaps involving an incorrect or
> missing setting somewhere.
>
> tl;dr: the stateID returned after saving the state seems to include
> lots of additional parts to it, including URLs. That does not look
> right to me.

Actually, you are seeing the "restart URL". This is something we use to
provide a fallback when people bookmark the login page. In your case it
may not be very useful, so dropping it is safe. Of course, if the user
somehow manages to return to the authentication handler with an invalid
or expired state ID, they will get the "State information lost" error.

With recent versions you can get only the state ID by passing TRUE as
the third parameter to saveState().

[Jason Judge]

$stateId = SimpleSAML_Auth_State::saveState($state,
'authcustom:External', true);

Brilliant - thanks :-)