Automatically login the user after registration
543 views
Skip to first unread message
Martyn Bissett
Jan 28, 2015, 2:34:01 AM1/28/15
to simple...@googlegroups.com
Is there a way that I can login a user from a PHP script if I have their username and password? I have created a sign up process where the user can sign up to the database on the IdP side from the SP. Once they have signed up, my app on the SP side instructs them to login in (link provided). They then click a link and proceed to the login page on the IdP. Our client really doesn't want this and it seems I need to find some means to automatically login the user upon registering (regiser username/password/etc, then seamlessly log the user in from the SP). Before I go on a search to see if it can be done, only to run into a whole bunch or errors/ problems, thought it best to ask. On the SP side, I'll have their username and password - is this at all possible? Even if I had to simulate the HTTP requests using curl or something? Or does this create a whole bunch of potential issues? I'm not sure if our client will be too pleased with "our SSO tool can't do it, so we're stuck" .. I've a feeling the response might be "well change the SSO tool then" - which would suck (and I'm not even sure if other SSO libraries I'm aware of, e.g. Cas, would manage this either). Would really appreciate any advise on this. Thanks
Dick Visser
Jan 28, 2015, 5:04:13 AM1/28/15
to simplesamlphp
On Wed, Jan 28, 2015 at 8:34 AM, Martyn Bissett <marty...@gmail.com> wrote:
>
> Is there a way that I can login a user from a PHP script if I have their username and password? I have created a sign up process where the user can sign up to the database on the IdP side from the SP.
Did you use the selfregister module for this, or did you create the
>
> Is there a way that I can login a user from a PHP script if I have their username and password? I have created a sign up process where the user can sign up to the database on the IdP side from the SP.
'sign-up process' yourself?
--
Dick Visser
Sr. System & Networking Engineer
GÉANT Association, Amsterdam Office (formerly TERENA)
Singel 468D, 1017 AW Amsterdam, the Netherlands
Tel: +31 (0) 20 530 4488
GÉANT Association
Networking. Services. People.
Learn more at: http://www.géant.org
Martyn Bissett
Jan 28, 2015, 5:32:22 AM1/28/15
to simple...@googlegroups.com
Actually we built our own. The user registers from a form on the SP side, the form handler script makes a curl request to our register handler from there to register on the IdP. We have various SP related additional fields so this approach suites us. The register API isn't part of SSP either (e.g. not a module). Would this make it easier if the register API were a module like selfregister?
Dick Visser
Jan 28, 2015, 6:49:32 AM1/28/15
to simplesamlphp
On Wed, Jan 28, 2015 at 11:32 AM, Martyn Bissett <marty...@gmail.com> wrote:
>
> Actually we built our own. The user registers from a form on the SP side, the form handler script makes a curl request to our register handler from there to register on the IdP. We have various SP related additional fields so this approach suites us. The register API isn't part of SSP either (e.g. not a module). Would this make it easier if the register API were a module like selfregister?
Not really, I was trying to see if there hadn't been any wheel reinvention ;-)
>
> Actually we built our own. The user registers from a form on the SP side, the form handler script makes a curl request to our register handler from there to register on the IdP. We have various SP related additional fields so this approach suites us. The register API isn't part of SSP either (e.g. not a module). Would this make it easier if the register API were a module like selfregister?
But in your case it's a tailored sign-up process.
I'm not sure about the possibilities of auto-login, but since you
control both IdP and SP, I'd say there should be options.
Dick
>
>
>
>
>
> On Wednesday, 28 January 2015 19:04:13 UTC+9, Dick Visser wrote:
>>
>> On Wed, Jan 28, 2015 at 8:34 AM, Martyn Bissett <marty...@gmail.com> wrote:
>> >
>> > Is there a way that I can login a user from a PHP script if I have their username and password? I have created a sign up process where the user can sign up to the database on the IdP side from the SP.
>>
>> Did you use the selfregister module for this, or did you create the
>> 'sign-up process' yourself?
>>
>>
>> --
>> Dick Visser
>> Sr. System & Networking Engineer
>> GÉANT Association, Amsterdam Office (formerly TERENA)
>> Singel 468D, 1017 AW Amsterdam, the Netherlands
>> Tel: +31 (0) 20 530 4488
>>
>> GÉANT Association
>> Networking. Services. People.
>>
>> Learn more at: http://www.géant.org
>
> 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.
Jaime Perez Crespo
Jan 28, 2015, 9:35:04 AM1/28/15
to simple...@googlegroups.com
Hi Martin,
> On 28 Jan 2015, at 11:32 am, Martyn Bissett <marty...@gmail.com> wrote:
> Actually we built our own. The user registers from a form on the SP side, the form handler script makes a curl request to our register handler from there to register on the IdP. We have various SP related additional fields so this approach suites us. The register API isn't part of SSP either (e.g. not a module). Would this make it easier if the register API were a module like selfregister?
I’m afraid there’s no way to solve your problem, since you are doing the registration back-channel instead of front-channel (that is, using curl at the SP’s server rather than submitting the form through the user’s browser). Even if you login to the IdP using the same back-channel connection, it’s the server the one who gets the cookie that holds the session. The SP cannot just send that cookie to the browser since the domain will not match. What you could do is to create a session manually on the SP, but then the user would be logged in into the SP, not into the IdP, and you won’t have Single Sign On.
The root of your problem is that you are doing things wrong. The IdP is the one that holds the identity of the user, and the SP just consumes it. If you are using the SP to register an account at the IdP, that’s wrong and you shouldn’t do that. If you need self-registration, that must happen at the IdP, which is the one that holds the database. Since you are accessing the database directly from the SP, you don’t really need to have an SP and an IdP, but if you have them I guess that’s because you need Single Sign On with other applications, in which case you simply cannot accomplish what you are trying to do.
I understand that this strange scenario must have been something you have been required to do, but you should tell your client what they want to do is wrong and will create trouble (not only because there’s things they want that cannot work, but also because it implies security risks).
Now, if the issue for your client is that they need to store application-specific information for the users, that’s no valid reason to handle the registration at the SP. If you need your own attributes at the SP, what you basically do is to require a unique identifier from the IdP, and use that to match a local account that contains the application-specific information. Then you have two different ways to proceed with local accounts: either you do a pre-provisioning (creating them on before hand), or you do provisioning when the user logs in for the first time.
In any case, if you could give us some background on what the system looks like and what are the requirements, we can try to point you out in the right direction.
--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no
"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost
> On 28 Jan 2015, at 11:32 am, Martyn Bissett <marty...@gmail.com> wrote:
> Actually we built our own. The user registers from a form on the SP side, the form handler script makes a curl request to our register handler from there to register on the IdP. We have various SP related additional fields so this approach suites us. The register API isn't part of SSP either (e.g. not a module). Would this make it easier if the register API were a module like selfregister?
The root of your problem is that you are doing things wrong. The IdP is the one that holds the identity of the user, and the SP just consumes it. If you are using the SP to register an account at the IdP, that’s wrong and you shouldn’t do that. If you need self-registration, that must happen at the IdP, which is the one that holds the database. Since you are accessing the database directly from the SP, you don’t really need to have an SP and an IdP, but if you have them I guess that’s because you need Single Sign On with other applications, in which case you simply cannot accomplish what you are trying to do.
I understand that this strange scenario must have been something you have been required to do, but you should tell your client what they want to do is wrong and will create trouble (not only because there’s things they want that cannot work, but also because it implies security risks).
Now, if the issue for your client is that they need to store application-specific information for the users, that’s no valid reason to handle the registration at the SP. If you need your own attributes at the SP, what you basically do is to require a unique identifier from the IdP, and use that to match a local account that contains the application-specific information. Then you have two different ways to proceed with local accounts: either you do a pre-provisioning (creating them on before hand), or you do provisioning when the user logs in for the first time.
In any case, if you could give us some background on what the system looks like and what are the requirements, we can try to point you out in the right direction.
--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no
"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost
Martyn Bissett
Jan 28, 2015, 9:14:55 PM1/28/15
to simple...@googlegroups.com
Hi Jaime,
Thanks for the very detailed response, I'll explain a little more in detail if I didn't before. By the way, we don't store authentication details on the SP. For example, the SP does not store user passwords. But, each SP has fields (e.g. user settings, their role such members/ admin, display name etc - for that SP only) that are specific to that SP only. If we store all of that data on the IdP, for all SPs. which isn't related to authentication anyway, our IdP might become a little messy.
Thanks for the very detailed response, I'll explain a little more in detail if I didn't before. By the way, we don't store authentication details on the SP. For example, the SP does not store user passwords. But, each SP has fields (e.g. user settings, their role such members/ admin, display name etc - for that SP only) that are specific to that SP only. If we store all of that data on the IdP, for all SPs. which isn't related to authentication anyway, our IdP might become a little messy.
I’m afraid there’s no way to solve your problem, since you are doing the registration back-channel instead of front-channel (that is, using curl at the SP’s server rather than submitting the form through the user’s browser). Even if you login to the IdP using the same back-channel connection, it’s the server the one who gets the cookie that holds the session. The SP cannot just send that cookie to the browser since the domain will not match. What you could do is to create a session manually on the SP, but then the user would be logged in into the SP, not into the IdP, and you won’t have Single Sign On.
The root of your problem is that you are doing things wrong. The IdP is the one that holds the identity of the user, and the SP just consumes it. If you are using the SP to register an account at the IdP, that’s wrong and you shouldn’t do that. If you need self-registration, that must happen at the IdP, which is the one that holds the database. Since you are accessing the database directly from the SP, you don’t really need to have an SP and an IdP, but if you have them I guess that’s because you need Single Sign On with other applications, in which case you simply cannot accomplish what you are trying to do.
On the SP side, the user is presented with a form. Upon submitting that form (username, password, email, and any additional fields such as display name for that SP app), the form action script on the SP side will first, via curl request, POST the username, password and email to the IdP POST script handler registering the user there. Once confirmation is returned to the SP side that the user has been added to the IdP, the an account is created on the SP side with any SP relevant fields such as display name. So just to summarize - authentication details are held on the IdP but some additional fields are stored on the SP linked by a unique username.
So, when the user logins in - this is all done on the IdP side (user clicks login link, redirected to IdP login screen, enters credentials, redirected back to the SP and SSP cookie is created for the domain)
I understand that this strange scenario must have been something you have been required to do, but you should tell your client what they want to do is wrong and will create trouble (not only because there’s things they want that cannot work, but also because it implies security risks).
Now, if the issue for your client is that they need to store application-specific information for the users, that’s no valid reason to handle the registration at the SP. If you need your own attributes at the SP, what you basically do is to require a unique identifier from the IdP, and use that to match a local account that contains the application-specific information. Then you have two different ways to proceed with local accounts: either you do a pre-provisioning (creating them on before hand), or you do provisioning when the user logs in for the first time.
We are considering a single registration form on the IdP though. We could create default values for app specific fields, or we prompt em the first time they log in. However, whether we have the user register via the SP using curl to POST to the IdP, or we do the alternative - we're still storing authentication details only on the IdP. And, we would still want to have user related information which is relevant to that SP app only and tied by unique identifier (such as username) on the SP I think.
In any case, if you could give us some background on what the system looks like and what are the requirements, we can try to point you out in the right direction.
Anyway thanks again for your help. It would be great though if some means existed for automatically signing a user on, but I certainly don't want to jeopardize security in doing so, so I really appreciate your suggestion. If it doesn't currently exist in SSP, is it something that could be implemented? Or is the very SAML process and the means in which the IdP identifies users on different domains make it very difficult if not impossible?
Jaime Perez Crespo
Jan 29, 2015, 7:44:30 AM1/29/15
to simple...@googlegroups.com
Hi Martin,
> On 29 Jan 2015, at 03:14 am, Martyn Bissett <marty...@gmail.com> wrote:
> Thanks for the very detailed response, I'll explain a little more in detail if I didn't before. By the way, we don't store authentication details on the SP. For example, the SP does not store user passwords. But, each SP has fields (e.g. user settings, their role such members/ admin, display name etc - for that SP only) that are specific to that SP only. If we store all of that data on the IdP, for all SPs. which isn't related to authentication anyway, our IdP might become a little messy.
Yes, I assumed you were creating the accounts at the IdP, but thought that also the SP-specific attributes were there.
> On the SP side, the user is presented with a form. Upon submitting that form (username, password, email, and any additional fields such as display name for that SP app), the form action script on the SP side will first, via curl request, POST the username, password and email to the IdP POST script handler registering the user there.
There’s no way to make that work, you need to make the request front-channel. That also implies that the IdP would have some mechanism to: first, log you in after registration, and second, return to the URL that “posted” the registration form. Not very usable, I think…
> Once confirmation is returned to the SP side that the user has been added to the IdP, the an account is created on the SP side with any SP relevant fields such as display name. So just to summarize - authentication details are held on the IdP but some additional fields are stored on the SP linked by a unique username.
Ok, so you actually have automatic provisioning at the SP, sort of, at least. Why not doing that when the user accesses the SP for the first time? What happens with users that already have an account at the IdP, but not at an SP?
> So, when the user logins in - this is all done on the IdP side (user clicks login link, redirected to IdP login screen, enters credentials, redirected back to the SP and SSP cookie is created for the domain)
Yes, that’s absolutely correct.
> We are considering a single registration form on the IdP though. We could create default values for app specific fields, or we prompt em the first time they log in.
The latter is the way to go. You cannot register a user and all the attributes needed by all SPs, anyway, so why bothering at every single SP? Let the user register at the IdP, and then if something else is needed at a specific SP, ask for it.
> However, whether we have the user register via the SP using curl to POST to the IdP, or we do the alternative - we're still storing authentication details only on the IdP. And, we would still want to have user related information which is relevant to that SP app only and tied by unique identifier (such as username) on the SP I think.
Yes, and that’s absolutely legitimate, most service providers work like that. It just means you need to store data about your users at both sides (the IdP and the SPs).
> Anyway thanks again for your help. It would be great though if some means existed for automatically signing a user on, but I certainly don't want to jeopardize security in doing so, so I really appreciate your suggestion. If it doesn't currently exist in SSP, is it something that could be implemented? Or is the very SAML process and the means in which the IdP identifies users on different domains make it very difficult if not impossible?
No prob, glad to help!
The problem with security is that if you get your users accustomed to entering details like their password at places different than the IdP (that meaning, looking different, and having different domains), then it’s easier to trick them to give away their credentials. There’s also a different issue, which is your service providers actually getting the user’s password. When you perform registration at the SP (even if you are storing the account in the IdP), you are in a way breaking the trust model on which an identity federation relies.
AFAICT, you could use the selfregister module with SSP to allow users to register on their own. I don’t know if it logs you in automatically right after registration, though. If not, I guess that should be quite easy to implement, and I’m sure Dick Visser will be happy to include it in the module.
So to summarize, what I would do recommend you to do:
- All SPs delegate authentication *unconditionally* to the IdP. No “register here” link, just a login link.
- The IdP provides a “register here” link, pointing either to the selfregister module or to your home-made solution if that fits better your needs.
- When a user accesses an SP for the first time (being authenticated, of course), perform automatic provisioning.
- If the SP needs to store more information for its users, make it ask for it right after automatic provisioning.
Hope it helps. Just tell us if we can help you with anything else :-)
> On 29 Jan 2015, at 03:14 am, Martyn Bissett <marty...@gmail.com> wrote:
> Thanks for the very detailed response, I'll explain a little more in detail if I didn't before. By the way, we don't store authentication details on the SP. For example, the SP does not store user passwords. But, each SP has fields (e.g. user settings, their role such members/ admin, display name etc - for that SP only) that are specific to that SP only. If we store all of that data on the IdP, for all SPs. which isn't related to authentication anyway, our IdP might become a little messy.
> On the SP side, the user is presented with a form. Upon submitting that form (username, password, email, and any additional fields such as display name for that SP app), the form action script on the SP side will first, via curl request, POST the username, password and email to the IdP POST script handler registering the user there.
> Once confirmation is returned to the SP side that the user has been added to the IdP, the an account is created on the SP side with any SP relevant fields such as display name. So just to summarize - authentication details are held on the IdP but some additional fields are stored on the SP linked by a unique username.
> So, when the user logins in - this is all done on the IdP side (user clicks login link, redirected to IdP login screen, enters credentials, redirected back to the SP and SSP cookie is created for the domain)
> We are considering a single registration form on the IdP though. We could create default values for app specific fields, or we prompt em the first time they log in.
> However, whether we have the user register via the SP using curl to POST to the IdP, or we do the alternative - we're still storing authentication details only on the IdP. And, we would still want to have user related information which is relevant to that SP app only and tied by unique identifier (such as username) on the SP I think.
> Anyway thanks again for your help. It would be great though if some means existed for automatically signing a user on, but I certainly don't want to jeopardize security in doing so, so I really appreciate your suggestion. If it doesn't currently exist in SSP, is it something that could be implemented? Or is the very SAML process and the means in which the IdP identifies users on different domains make it very difficult if not impossible?
The problem with security is that if you get your users accustomed to entering details like their password at places different than the IdP (that meaning, looking different, and having different domains), then it’s easier to trick them to give away their credentials. There’s also a different issue, which is your service providers actually getting the user’s password. When you perform registration at the SP (even if you are storing the account in the IdP), you are in a way breaking the trust model on which an identity federation relies.
AFAICT, you could use the selfregister module with SSP to allow users to register on their own. I don’t know if it logs you in automatically right after registration, though. If not, I guess that should be quite easy to implement, and I’m sure Dick Visser will be happy to include it in the module.
So to summarize, what I would do recommend you to do:
- All SPs delegate authentication *unconditionally* to the IdP. No “register here” link, just a login link.
- The IdP provides a “register here” link, pointing either to the selfregister module or to your home-made solution if that fits better your needs.
- When a user accesses an SP for the first time (being authenticated, of course), perform automatic provisioning.
- If the SP needs to store more information for its users, make it ask for it right after automatic provisioning.
Hope it helps. Just tell us if we can help you with anything else :-)
Peter Schober
Jan 29, 2015, 8:16:24 AM1/29/15
to simple...@googlegroups.com
* Jaime Perez Crespo <jaime...@uninett.no> [2015-01-29 13:44]:
did /not/ create an IDP/SSO session after registration. One could
argue that this way subjects have to test the process at least once,
but I'd also agree that fewer obstacles in the way are preferrable,
i.e. +1 to the feature request of boostrapping an IDP session after
the registration has successfully completed.
There are other issues with selfregister (e.g. it does not re-send
verification emails if the subject changes her email, so we disabled
change of email address as a workaround), but that's not the time and
place to go into those.
-peter
> AFAICT, you could use the selfregister module with SSP to allow
> users to register on their own. I don’t know if it logs you in
> automatically right after registration, though. If not, I guess that
> should be quite easy to implement, and I’m sure Dick Visser will be
> happy to include it in the module.
Last time I checked (before Dick started working on this) selfregister
> users to register on their own. I don’t know if it logs you in
> automatically right after registration, though. If not, I guess that
> should be quite easy to implement, and I’m sure Dick Visser will be
> happy to include it in the module.
did /not/ create an IDP/SSO session after registration. One could
argue that this way subjects have to test the process at least once,
but I'd also agree that fewer obstacles in the way are preferrable,
i.e. +1 to the feature request of boostrapping an IDP session after
the registration has successfully completed.
There are other issues with selfregister (e.g. it does not re-send
verification emails if the subject changes her email, so we disabled
change of email address as a workaround), but that's not the time and
place to go into those.
-peter
Jaime Perez Crespo
Jan 29, 2015, 9:13:49 AM1/29/15
to simple...@googlegroups.com
Thanks for the info Peter!
> On 29 Jan 2015, at 14:16 pm, Peter Schober <peter....@univie.ac.at> wrote:
> Last time I checked (before Dick started working on this) selfregister
> did /not/ create an IDP/SSO session after registration. One could
> argue that this way subjects have to test the process at least once,
> but I'd also agree that fewer obstacles in the way are preferrable,
> i.e. +1 to the feature request of boostrapping an IDP session after
> the registration has successfully completed.
Yes, the easier for the user (while keeping security), the better. In this case I would say if the user already typed his or her password twice and both matched, the chances that the password was actually wrong are quite low. Besides, making the user login immediately after registration only helps to diagnose the problem, but not to solve it.
So in this case I think bootstrapping the session really makes sense.
> There are other issues with selfregister (e.g. it does not re-send
> verification emails if the subject changes her email, so we disabled
> change of email address as a workaround), but that's not the time and
> place to go into those.
Well, those things are important too. Maybe you could open issues in the issue tracker with any problems you’ve experienced with the module? I’m already bugging Dick with pull requests to make the module work with the master branch of SSP, so I guess I might already owe him a beer... :-)
> On 29 Jan 2015, at 14:16 pm, Peter Schober <peter....@univie.ac.at> wrote:
> Last time I checked (before Dick started working on this) selfregister
> did /not/ create an IDP/SSO session after registration. One could
> argue that this way subjects have to test the process at least once,
> but I'd also agree that fewer obstacles in the way are preferrable,
> i.e. +1 to the feature request of boostrapping an IDP session after
> the registration has successfully completed.
So in this case I think bootstrapping the session really makes sense.
> There are other issues with selfregister (e.g. it does not re-send
> verification emails if the subject changes her email, so we disabled
> change of email address as a workaround), but that's not the time and
> place to go into those.
Peter Schober
Jan 29, 2015, 9:26:35 AM1/29/15
to simple...@googlegroups.com
* Jaime Perez Crespo <jaime...@uninett.no> [2015-01-29 15:13]:
> Well, those things are important too. Maybe you could open issues in
> the issue tracker with any problems you’ve experienced with the
> module?
I'll see what I can come up with (i.e., try to find my local notes or
tickets).
-peter
> So in this case I think bootstrapping the session really makes
> sense.
OK!
> sense.
> Well, those things are important too. Maybe you could open issues in
> the issue tracker with any problems you’ve experienced with the
> module?
tickets).
-peter
Martyn Bissett
Jan 29, 2015, 9:08:43 PM1/29/15
to simple...@googlegroups.com, peter....@univie.ac.at
Thanks for the responses. Pleased to hear that it would be a welcomed addition.
So if the user makes a front channel request by clicking the login link (going through the SSP installation on the SP, before being redirected to the IdP). Then, the user registers and the new account is created. The meta information required (capture at the time of front channel request) to identify that individual could have been held until successful registration was complete, thereafter the system could proceed with the original login request that was made initially at the start? Is that kinda correct?
Actually I've had a little play around with selfregister. We want to go in the direction of a single sign up form on the IdP so I'll probably use it more and adapt the registration process to our needs. If there is anything I feel I can contribute I'll bring it up, I don't have a firm understanding of SSP as a whole yet though. I'll certainly keep an eye on any future developments too.
So if the user makes a front channel request by clicking the login link (going through the SSP installation on the SP, before being redirected to the IdP). Then, the user registers and the new account is created. The meta information required (capture at the time of front channel request) to identify that individual could have been held until successful registration was complete, thereafter the system could proceed with the original login request that was made initially at the start? Is that kinda correct?
Actually I've had a little play around with selfregister. We want to go in the direction of a single sign up form on the IdP so I'll probably use it more and adapt the registration process to our needs. If there is anything I feel I can contribute I'll bring it up, I don't have a firm understanding of SSP as a whole yet though. I'll certainly keep an eye on any future developments too.
Reply all
Reply to author
Forward
0 new messages