Sending default username to the login forms
Jason Judge
user update site, ...) with users authenticated against a remote CRM
through a SOAP API.
Now, when a user attempts to register on the website, the website
first checks whether their email address already exists on the CRM
with a password, and if it does, it sends them to the SSP login,
using:
$as = SimpleSAML\SSP::SimpleSAML_Auth_Simple(); // SSP is
wrapped in a FuelPHP package
$as->requireAuth(array(
'ReturnTo' => $return_url,
'KeepPost' => FALSE,
));
Now, at this point the user has already entered their email address,
which is used as their username. Is there any way I can pass this
email in at this point, so it can be accessed by the login form in the
IdP? I just want the user to avoid having to enter their email address
a second time.
Once the user gets to the login form, then may find they have
forgotten their password, and so will need to go forward to the
password recovery page (also in FuelPHP). So the email address would
be passed on that link too. You can see how the user could get very
confused potentially having to enter their email address yet again,
and then *again* to log in after they reset their password.
Just getting this piece of arbitrary data into SSP so that it can be
pulled out in the login form (the "authentication module" - I think)
is what I am looking for. SSP does not have to do anything with that
data item - just carry it along. Some of the websites are on the same
domain as the IdP, but some are not.
Thanks,
-- Jason
Olav Morken
There is (as far as I know at least) no standard for transporting it
through SAML 2.0 authentication requests. It is possible to get it
through by defining your own protocol extension, but that means adding
support for that extension on both the SP and IdP.
By default, the simpleSAMLphp IdP will store known and unknown
extensions in the saml:Extensions field in the state array, so they
will be included when calling the authentication source. You will
probably have to create a custom authentication source in order to get
it into the login form though.
On the simpleSAMLphp SP side, you can add custom extensions to the
AuthnRequest by doing something like this:
$doc = new DOMDocument();
$element = $doc->createElementNS('your-extension-namespace-URI', 'your-extension-element');
$element->appendChild($doc->createTextElement('contents'));
$xmlChunk = new SAML2_XML_Chunk($element);
$as = ...;
$as->requireAuth(array(
[...],
'saml:Extensions' => array(
$xmlChunk,
),
));
Not entirely certain about the exact syntax, but I believe it is
something like that.
Of course, whether doing it this way is a good idea is another
question :) It means that you won't have full interoperability with
other SAML 2.0 implementations. It also requires a certain amount of
custom code to handle the extension.
Best regards,
Olav Morken
UNINETT / Feide
Jason Judge
paste. The only correction is Node rather than Element in the DOM:
$doc->createTextNode('contents')
My login form on the IdP is custom, so that I could add features like
this (and registration/forgot password/cancel links, etc). Dumping the
state, I see this in the array:
["saml:Extensions"]=>
array(1) {
[0]=>
object(SAML2_XML_Chunk)#6 (4) {
["localName"]=>
string(8) "username"
["namespaceURI"]=>
string(23) "http://www.example.com/"
["xml":"SAML2_XML_Chunk":private]=>
NULL
["xmlString":"SAML2_XML_Chunk":private]=>
string(64) "my_username"
}
}
I can see the data I need in there - my_username - but it is a private
property of the object. So my next question is, how do I get at that
property value? I expect there will be methods, but I am lost and
don't even know what I'm looking for. There seems to be documentation
on the "custom extension API", so I'll look there first, but any tips
would be appreciated.
In case I have misunderstood, I am passing data through for a "custom
extension", but there is no extension coded into either the IdP or the
SP beyond the code required to pass the data in, and get the data out
of the state?
-- Jason
Jason Judge
$state = SimpleSAML_Auth_State::loadState(...);
echo "The data name is: " . $state['saml:Extensions'][0]->getXML()-
>nodeName;
echo "The username is: " . $state['saml:Extensions'][0]->getXML()-
>nodeValue;
That gives me "username" and "my_username".
I suppose I have to scan all the extensions in a loop until I find one
with the right "namespaceURI" and "localName" properties, and then
take the value of that to give me the supplied username. Unless there
is a helper method in SSP that we do this for me?
-- Jason
Olav Morken
> Okay, I can get to the name and value in the IdP login form like this:
>
> $state = SimpleSAML_Auth_State::loadState(...);
> echo "The data name is: " . $state['saml:Extensions'][0]->getXML()-
> >nodeName;
> echo "The username is: " . $state['saml:Extensions'][0]->getXML()-
> >nodeValue;
>
> That gives me "username" and "my_username".
>
> I suppose I have to scan all the extensions in a loop until I find one
> with the right "namespaceURI" and "localName" properties, and then
> take the value of that to give me the supplied username. Unless there
> is a helper method in SSP that we do this for me?
No helper function, but note that namespaceURI and localName are public
properties of the SAML2_XML_Chunk datatype. That should reduce the
overhead slightly.
However, not all saml:Extensions-elements need to be of the type
SAML2_XML_Chunk. (If it is a known extension, it will be parsed into
an appropriate object. Of course, there are no known extensions here
yet, but there may be in the future :)
A proper loop would be something like:
function getUsername(array $state) {
if (!isset($state['saml:Extensions'])) {
// No extensions in message.
return NULL;
}
foreach ($state['saml:Extensions'] as $ext) {
if (!$ext instanceof SAML2_XML_Chunk) {
continue; // Not our extension type - continue searching.
}
if ($ext->namespaceURI !== 'yournamespace' || $ext->localName !== 'yourelementname') {
continue; // Not our element - continue searching.
}
// We have the correct element - extract the username.
$xml = $ext->getXML();
$username = $xml->textContent;
return $username;
}
// We did not find our extension.
return NULL;
Jason Judge
check, and changed my $xml->NodeValue to $xml->textContent (both are
returning the same string) and now it works a treat!
Thank you for your help. I *personally* find the code-base and
documentation for SSP to be very "academic" (correct, precise, but
needs an incredible amount of study to work out how to use it and how
it works) and very hard to follow. It is designed to cater for any
possible need, so fathoming out which bits are relevant to a specific
use-case is pretty difficult. However, each time I get help here,
another piece of the puzzle clicks into place.
Thanks.
-- Jason
:-)
Jason Judge
group posts - second to none :-)
Jason Judge
I just did not understand what it was about and why it needed to be
used like it does. Now I realise the authentication class, by default,
does not involve any user interactive elements. Where it does need to
interact with the user, the state is passed from the back-end
authentication code to the front-end code (in the module's www
directory).
For people who have been working on this project for a long time,
concepts like that are probably pretty obvious. But for people coming
to the project fresh, pulling that out of the documentation is hard,
very hard. I wonder if maybe there is an intermediate level missing -
perhaps the framework described in some diagramatic form. Once the
concepts of how it works, and what the parts of it are, the
documentation can then point to where the components are and how to
configure them.
Perhaps it is just me? My aim isn't to criticise, but to point out
areas that I believe may be holding back vast numbers of projects
making use of this project (which may or may not be a blessing in
disguise;-) just based on my own personal experience.
-- Jason
Sean Harbour
>From: simple...@googlegroups.com [simple...@googlegroups.com] on behalf of Jason Judge [jason....@gmail.com]
>Sent: Wednesday, January 25, 2012 3:19 AM
>To: simpleSAMLphp
>Subject: Re: Sending default username to the login forms
I agree, it would be very helpful for those admins like myself who are not full time programmers to be able to see a conceptual diagram of the authentication process (with notes referencing what modules do what) before beginning to install and customize simpleSAMLphp.
Thanks,
Sean
Jason Judge
On Jan 25, 3:45 pm, Sean Harbour <SHarb...@nwresd.k12.or.us> wrote:
> >________________________________________
write it ;-) I would be happy to provide input where I can (I can
explain what is not clear to a newbie like myself) but I don't feel I
understand it enough to describe it correctly to others.
One problem I have found with many (or most) of the examples I have
seen, is that they are not upgrade safe. All examples of how to set
things up tend to involve editing files that will be over-written on
an upgrade. It would be nice to know how to set up a system where all
the custom files are new - a new module, a new config area, new entry
points etc. so SSP sits unaltered in one place, and all the custom
code sits separately to it. I do get the impression this is how it
should work, but finding out how to do that is not easy. I would be
happy to write up or draw up an example of how that could be done, for
a small ring-fenced set of sites requiring SSO (that's my use-case,
and it works as I have set it up, but I feel it needs some refactoring
to do it "properly").
-- Jason
Olav Morken
>
>
> On Jan 25, 3:45�pm, Sean Harbour <SHarb...@nwresd.k12.or.us> wrote:
> > >________________________________________
> > >From: simple...@googlegroups.com [simple...@googlegroups.com] on behalf of Jason Judge [jason.dju...@gmail.com]
> > >Just to add to this, the state and save-state stuff really stumped me.
> > >I just did not understand what it was about and why it needed to be
> > >used like it does. Now I realise the authentication class, by default,
> > >does not involve any user interactive elements. Where it does need to
> > >interact with the user, the state is passed from the back-end
> > >authentication code to the front-end code (in the module's www
> > >directory).
It is designed to be flexible, but the price of that is complexity.
We have tried to provide a simple wrapper-class (UserPassBase) to
abstract away the most common code. But that fails when you have
special requirements, such as when you need to receive the
username from the SP.
> > >For people who have been working on this project for a long time,
> > >concepts like that are probably pretty obvious. But for people coming
> > >to the project fresh, pulling that out of the documentation is hard,
> > >very hard. I wonder if maybe there is an intermediate level missing -
> > >perhaps the framework described in some diagramatic form. Once the
> > >concepts of how it works, and what the parts of it are, the
> > >documentation can then point to where the components are and how to
> > >configure them.
> > >
> > >Perhaps it is just me? My aim isn't to criticise, but to point out
> > >areas that I believe may be holding back vast numbers of projects
> > >making use of this project (which may or may not be a blessing in
> > >disguise;-) just based on my own personal experience.
It's probably not just you. The problem is always time, and the lack
of it :)
> >
> > >-- Jason
> >
> > I agree, it would be very helpful for those admins like myself who are not full time programmers to be able to see a conceptual diagram of the authentication process (with notes referencing what modules do what) before beginning to install and customize simpleSAMLphp.
I made an attempt at creating a document displaying the authentication
process in a simpleSAMLphp IdP. See the attached file. Is that the type
of diagram that you are looking for? Of course, one would also need
some text to describe the purpose of the various boxes.
> >
> > Thanks,
> >
> > Sean
>
> Asking for something like this usually results in being volunteered to
> write it ;-) I would be happy to provide input where I can (I can
> explain what is not clear to a newbie like myself) but I don't feel I
> understand it enough to describe it correctly to others.
>
> One problem I have found with many (or most) of the examples I have
> seen, is that they are not upgrade safe. All examples of how to set
> things up tend to involve editing files that will be over-written on
> an upgrade.
What examples would that be? Not from our documentation I hope?
> It would be nice to know how to set up a system where all
> the custom files are new - a new module, a new config area, new entry
> points etc. so SSP sits unaltered in one place, and all the custom
> code sits separately to it. I do get the impression this is how it
> should work, but finding out how to do that is not easy. I would be
> happy to write up or draw up an example of how that could be done, for
> a small ring-fenced set of sites requiring SSO (that's my use-case,
> and it works as I have set it up, but I feel it needs some refactoring
> to do it "properly").
Best regards,
Jason Judge
On Jan 27, 12:53 pm, Olav Morken <olav.mor...@uninett.no> wrote:
> On Thu, Jan 26, 2012 at 04:33:53 -0800, Jason Judge wrote:
>
> 36KViewDownload
Olav - that is very good :-) Even without the description, it puts a
lot of the pieces of the puzzle into context. This shows the flow of
processing through the authentication process.
A diagram that I was just thinking would also be helpful, is a logical
data flow digram. I'm not sure if that is what it would be called, but
logically we see that there are objects available to certain stages in
the process, and data can be pushed into those objects in one place,
and pulled out again somewhere else, on another server or domain.
Behind the scenes "magic" works to make this happen, but knowing what
that data is, where and how it can be accessed, and what it does,
would answer a lot of the questions I see on this group.
For example, I have user information fetched by the authentication
form in an authpage of a custom module. I want to pass those details
back to the Auth Source class (if that is the right term) so that it
gets back to the SP. Do I pop those details in the session and pull
then out again in the Auth Source class? Or do I push it into the
state somewhere and it becomes available in the Auth Source that way?
A "push it in here and pull it out again there" type of diagram would
really help me here, especially as the names and terms of all these
components are still new to me, and I guess I am using many of them
wrongly anyway, so it is even difficult to know how to ask the right
question.
But that diagram - yes - we need more of those :-)
-- Jason
Tom Scavo
>
> For example, I have user information fetched by the authentication
> form in an authpage of a custom module. I want to pass those details
> back to the Auth Source class (if that is the right term) so that it
> gets back to the SP.
The SP is logically (and most often physically) separate from the IdP,
so to do that you have to encode the information in SAML (since that's
how the SP and IdP communicate). Since you seem to be talking about
authentication information, you might want to look at SAML
AuthnContext, which was invented for this very purpose. Note, however,
that although SAML V2.0 has been in use for quite some time, the use
of AuthnContext is still in its infancy.
Tom