idp-first configuration
21 views
Skip to first unread message
Dallas Despain
Jul 11, 2012, 1:03:39 PM7/11/12
to drupa...@googlegroups.com
Can anybody tell me if the following idp-first flow is possible?
1. user goes to drupal idp site
2. user logs in.
3. user is presented with link to service provider (redirects through ssoservice)
4. since the user has already logged in to the drupal idp site, the user skips the simlesaml login form and is automatically sent on to the service provider.
As I have it set up now, the user still has to log in twice in an idp-first flow, which defeats the purpose of saml sso.
1. user goes to drupal idp site
2. user logs in.
3. user is presented with link to service provider (redirects through ssoservice)
4. since the user has already logged in to the drupal idp site, the user skips the simlesaml login form and is automatically sent on to the service provider.
As I have it set up now, the user still has to log in twice in an idp-first flow, which defeats the purpose of saml sso.
Do I have to theme simplesamlphp and make it look like it's the drupal login? That would make it so they only need to login once, and I suppose I could use RelayState to send them back to the idp landing page, but then I don't think they'll be logged in to the drupal idp.
Is there a way I could programatically get them authenticated through drupalauth? Maybe I could implement a drupal user_login hook or something that would programatically sign then into simplesamlphp so they don't have to login twice?
Thanks!
Is there a way I could programatically get them authenticated through drupalauth? Maybe I could implement a drupal user_login hook or something that would programatically sign then into simplesamlphp so they don't have to login twice?
Thanks!
Steve Moitozo II
Jul 16, 2012, 10:08:52 AM7/16/12
to drupa...@googlegroups.com
Sorry for the late reply Dallas. I've been traveling.
In its current state the drupalauth module doesn't work this way. An existing Drupal session is not bridged to SimpleSAMLphp. Rather, the way it works is that the drupalauth module creates an Authentication Source for SimpleSAMLphp that allows SimpleSAMLphp to authenticate a user against the Drupal API. As far as SimpleSAMLphp is concerned its as if the user authenticated against any other backend database.
Currently the only way to accomplish what you want to do is with one server, two fully qualified host names, two instances of SimpleSAMLphp, and one Drupal site. Let's say your Drupal site is www.example.com and your IdP is idp.example.com. You would install the SP instance of SimpleSAMLphp at www.example.com/simplesaml and the IdP instance at idp.example.com/simplesaml. The Drupal site would be configured to operate on www.example.com but not idp.example.com. The IdP instance of SimpleSAMLphp would be configured to authenticate users against the drupal site using drupalauth. The SP instance of SimpleSAMLphp would be configured to trust the IdP. Then, you would SAMLize Drupal using the simplesamlphp_auth module configured to use the SP instance of SimpleSAMLphp. This would require theme modifications to the IdP instance and it would require some shenanigans to make the account creation and log in flow work nicely.
I've done this but there are several undesirable implications of this configuration so I have recently been thinking about how I could modify drupalauth to use an existing Drupal session as proof of authentication. The benefit would be that they would never see the SimpleSAMLphp login page. This would have several benefits:
1) setting up a Drupal-backed IdP would not require any theme work to SimpleSAMLphp since the user would never interact with it
2) Drupal sessions could be used as proof of authentication and therefore it would simplify both the user's experience and the administrator's experience better
3) assuming the Drupal site didn't also need to be SAMLized (to support other IdPs) it would drastically reduce the requirements to one server, one instance of SimpleSAMLphp (IdP), and one instance of Drupal
To pull this off I will likely need to implement a Drupal module to help bridge the gap between Drupal and SimpleSAMLphp.
If this new approach seems favorable to you, as it does to at least one other group I've interacted with lately, then I'll put this on the roadmap for the drupalauth project.
In its current state the drupalauth module doesn't work this way. An existing Drupal session is not bridged to SimpleSAMLphp. Rather, the way it works is that the drupalauth module creates an Authentication Source for SimpleSAMLphp that allows SimpleSAMLphp to authenticate a user against the Drupal API. As far as SimpleSAMLphp is concerned its as if the user authenticated against any other backend database.
Currently the only way to accomplish what you want to do is with one server, two fully qualified host names, two instances of SimpleSAMLphp, and one Drupal site. Let's say your Drupal site is www.example.com and your IdP is idp.example.com. You would install the SP instance of SimpleSAMLphp at www.example.com/simplesaml and the IdP instance at idp.example.com/simplesaml. The Drupal site would be configured to operate on www.example.com but not idp.example.com. The IdP instance of SimpleSAMLphp would be configured to authenticate users against the drupal site using drupalauth. The SP instance of SimpleSAMLphp would be configured to trust the IdP. Then, you would SAMLize Drupal using the simplesamlphp_auth module configured to use the SP instance of SimpleSAMLphp. This would require theme modifications to the IdP instance and it would require some shenanigans to make the account creation and log in flow work nicely.
I've done this but there are several undesirable implications of this configuration so I have recently been thinking about how I could modify drupalauth to use an existing Drupal session as proof of authentication. The benefit would be that they would never see the SimpleSAMLphp login page. This would have several benefits:
1) setting up a Drupal-backed IdP would not require any theme work to SimpleSAMLphp since the user would never interact with it
2) Drupal sessions could be used as proof of authentication and therefore it would simplify both the user's experience and the administrator's experience better
3) assuming the Drupal site didn't also need to be SAMLized (to support other IdPs) it would drastically reduce the requirements to one server, one instance of SimpleSAMLphp (IdP), and one instance of Drupal
To pull this off I will likely need to implement a Drupal module to help bridge the gap between Drupal and SimpleSAMLphp.
If this new approach seems favorable to you, as it does to at least one other group I've interacted with lately, then I'll put this on the roadmap for the drupalauth project.
Dallas Despain
Jul 16, 2012, 4:58:23 PM7/16/12
to drupa...@googlegroups.com
Hi Steve,
Thanks very much for your reply and expertise. After I posted, I verified that drupalauth doesn't use an existing drupal session and I was considered what sort of drupal module one would need to share the session and I didn't get too far. Anyway, in answer to your question, I think the new approach sounds very favorable. For my part, my project has morphed and I no longer need simplesamlphp in the immediate term, but I think your plan is great and I'm sure it would be a great addition to the roadmap. It would also be great fur people looking on drupal.org for saml modules. Whatever you do might even possibly be linked into the current sp-only drupal module http://drupal.org/project/simplesamlphp_auth
Thanks!
Dallas
Reply all
Reply to author
Forward
0 new messages