Re: [Dataverse-Users] Shibboleth integration with passive login request

187 views
Skip to first unread message

Philip Durbin

unread,
Nov 28, 2016, 9:01:12 AM11/28/16
to dataverse...@googlegroups.com
Hi Alex,

There was a bit of a hiccup and I don't think your message was archived to the Google Group but hopefully this reply will be.

I've never heard of this passive login feature of Shibboleth. It sounds nice, and it sounds like what single sign on promises, which is the ability to log in once and then be logged in to various applications such as Dataverse and your Drupal application. It's not clear to me what changes would need to be made to the Shibboleth Service Provider (SP) configuration or to the Dataverse application itself, if any, but if you can figure it out and create a pull request, we could test it and make sure it doesn't break anything. We like pull requests to be tied to issues, so creating a GitHub issue first would be a good start.

I sort of have OAuth on the brain right now and I'm assuming this passive concept doesn't apply. That is to say, just because I've logged in to Trello using my Google account, I don't assume that I should be able to log into Dataverse without first telling Google that I authorize Dataverse to get some basic information about my Google account such as my name and email address. Mostly I bring this up because we'd like the experience for users of remote authentication to be roughly the same but I can understand if you're interested in making good use of a feature of Shibboleth that OAuth may not have.

I hope this helps,

Phil


On Sat, Nov 26, 2016 at 5:35 PM, Alexander Ivanov <al...@calmforce.com> wrote:

Hi all,

 

At QDR we are finalizing our Dataverse integration with Shibboleth.  We have successfully configured our Dataverse and Drupal sites to authenticate against our Shibboleth IdP.  Our Shibboleth SP is configured with two entity IDs, one for Drupal and one for Dataverse (shibboleth2.xml config file attached).

 

The problem is that after the user is authenticated for either Drupal or Dataverse, and then navigates to the other site, the other site does not recognize the user as being logged-in and the user needs to click on Login again to be authenticated for the second site.  For our SSO to work seamlessly, I would like to configure it so that the second site can recognize that the user has already been authenticated, and log the user in behind-the-scenes without any interaction from the user.

 

Here is my thread on the topic in the Shibboleth mailing list:

http://shibboleth.1660669.n2.nabble.com/Joint-SP-configuration-for-two-applications-attributePrefix-conflict-td7629689.html

 

I am trying to follow Scott Cantor’s advice in his reply from 11/25:

One way you haven't looked at is IsPassive. If you wanted to, your application could issue a passive login request to the IdP and if the user's already logged in, it will be seamless. With the Shibboleth SP, that's just a simple redirect to /Shibboleth.sso/Login?isPassive=1

 

The isPassive login request seems like a good solution for us.  Reference:

https://wiki.shibboleth.net/confluence/display/SHIB2/isPassive

 

However, this passive login does not seem to work for Dataverse.  When a user starts at the Dataverse site, authenticates with the IdP, then navigates to the Drupal site, and then a call is made to [Drupal domain]/Shibboleth.sso/Login?isPassive=1, the user is properly logged into the Drupal site.  However when I attempt to do the same thing by first logging into the Drupal site and then navigating to Dataverse, making a call to [Dataverse domain] /Shibboleth.sso/Login?isPassive=1 does create an SSO session for the Dataverse domain, but does not log the user into the Dataverse site.

 

Can such a passive login request to the Shibboleth IdP work for logging the user into Dataverse, or do I need to implement a different solution?

 

Thanks in advance for your help,

Alex

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/682ec462-4fba-4754-b203-7dda234b8e41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Message has been deleted
Message has been deleted

Philip Durbin

unread,
Nov 28, 2016, 10:12:00 PM11/28/16
to Dataverse Users Community
Great news, Alex! I'm glad you got it working!

Phil

p.s. For some reason your messages are still being marked as spam despite me clicking "Post and always allow future messages from author(s)" just now and back when I approved your original post this morning. Your original post wasn't archived but my reply was so hopefully this will get archived as well! I'm not sure what's going on.

On Mon, Nov 28, 2016 at 9:12 PM, Alexander Ivanov <al...@calmforce.com> wrote:
Thanks Phil.

I was just able to get passive login to work for Dataverse by supplying a target parameter in the url:
https://dv.stage.qdr.org/Shibboleth.sso/Login?target=https%3A%2F%2Fdv.stage.qdr.org%2Fshib.xhtml?isPassive=1

[Dataverse host]/shib.xhtml has to be supplied as the target parameter for the Shibboleth.sso/Login call, otherwise auto-login doesn't work, regardless of whether or not the isPassive parameter is used.

Also, for passive login, I found that I had to put the isPassive parameter after the target parameter in the query string, otherwise the call didn't work.

My best,
Alex
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsubscribe...@googlegroups.com.
 To post to this group, send email to dataverse...@googlegroups.com.
Message has been deleted

Philip Durbin

unread,
Nov 29, 2016, 9:04:43 AM11/29/16
to Dataverse Users Community
Hi Alex,

Since the JS file is related to Shibboleth I would recommend putting in along side these:

- src/main/webapp/resources/js/shib/idpselect.js
- src/main/webapp/resources/js/shib/idpselect_config.js
- src/main/webapp/resources/js/shib/idpselect_style.js

Are you thinking this would be a pull request? Others might be interested in this feature of being automatically logged into Dataverse if they've already logged in to some other app based on their institutional credentials. (An example for Harvard would be logging into Harvie or PeopleSoft and then being automatically logged in to Dataverse when you select Harvard from the Dataverse login page.) If so, please create an issue first so that we can track the development of the feature and put it through QA, etc. I think we'd want this feature off by default. Instructions would need to be provided to explain how to turn it on. If people love it, maybe some day we'd make it the default. :)

Thanks,

Phil

p.s. All of your messages are still being marked as spam. I keep approving them but then when I go to look at them in the archive, I see a message that says "This message has been deleted" where your post should be. You can see this if you scroll down at https://groups.google.com/d/msg/dataverse-community/Fc0wC4fLyeI/3crtMxIzDAAJ . I'm not sure what's going on. :(

On Mon, Nov 28, 2016 at 11:50 PM, Alexander Ivanov <al...@calmforce.com> wrote:
Yup, I got it to work.  I'd like to clarify that the order of the parameters in the query string actually does not matter, I had hastily created my query string with incorrect syntax.

Now I need to add some code to our Dataverse application that will perform the passive logins.  I will try to follow the JS example in the link below:
Sample JavaScript that can be used to have an auto-login in case a user already has a session at an IdP

Is there a page in the published guide for Dataverse that would cover the best place to put a custom JS file? 

Sebastian Karcher

unread,
Nov 29, 2016, 10:06:07 AM11/29/16
to dataverse...@googlegroups.com
Thanks Phil,
as I've discussed with Gustavo, too, we'll definitely write up our set-up so that others can benefit from our (i.e. Alex's) work on SSO. Once that's done, I think it makes sense for us to sit down briefly to discuss what/how we could contribute some of that back to DV, be it as issues-come-pull requests or "just" as documentation.
Really appreciate all your help on this,
Sebastian

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CABbxx8HmOn7-uC%3DLmTSS_hGqk4LVT5%2B_czqCxEv%3D06k%3DY7g9EQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Sebastian Karcher, PhD
www.sebastiankarcher.com
Message has been deleted
Message has been deleted
Message has been deleted

Alexander Ivanov

unread,
Apr 11, 2017, 3:04:39 AM4/11/17
to Dataverse Users Community, philip...@harvard.edu
Hey Phil,

I've created a pull request for this feature:

If this is something that others can benefit from, then let's review my code and merge it into the DV codebase

My Best,
Alex

On Monday, November 28, 2016 at 9:01:12 AM UTC-5, Philip Durbin wrote:
To post to this group, send email to dataverse...@googlegroups.com.

Philip Durbin

unread,
Apr 11, 2017, 7:32:03 AM4/11/17
to dataverse...@googlegroups.com
Thanks for the pull request, Alex! I left you a comment and put the pull request in Code Review at https://waffle.io/IQSS/dataverse so others can comment if they want to.

Phil

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/750fdb22-a186-4a34-8151-d87b8d7fa3bb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Kevin Condon

unread,
Apr 13, 2017, 11:55:45 AM4/13/17
to Dataverse Users Community, philip...@harvard.edu


On Tuesday, April 11, 2017 at 3:04:39 AM UTC-4, Alexander Ivanov wrote:
Hey Phil,

I've created a pull request for this feature:

If this is something that others can benefit from, then let's review my code and merge it into the DV codebase

My Best,
Alex

Hi Alex,

I'm QA'ing your pull request before we merge it. Can you make a Github commit to add some documentation to the guides on how to use it and can you tell me how I might test this?

Thanks,

Kevin

I've read through the thread, looked at your commit and this is what I think I know:

Problem being solved:


The problem is that after the user is authenticated for either Drupal or Dataverse, and then navigates to the other site, the other site does not recognize the user as being logged-in and the user needs to click on Login again to be authenticated for the second site.  For our SSO to work seamlessly, I would like to configure it so that the second site can recognize that the user has already been authenticated, and log the user in behind-the-scenes without any interaction from the user.


Recommended solution is to use isPassive flag from Shibboleth protocol:


Use isPassive:

https://wiki.shibboleth.net/confluence/display/SHIB2/isPassive


Requirements:


- Only works if a Service Provider 2.x is installed on the same host

- JavaScript must be enabled. Otherwise the script won't have any effect.

- The script must be able to set cookies (required for Shibboleth Service Provider as well)

- In the shibboleth2.xml there must be defined a redirectErrors="#THIS PAGE#" in

  the <Errors> element. #THIS PAGE# must be the relative/absolute URL of the page

  this script is embedded in.

- It also makes sense to protect #THIS PAGE# with a lazy session in order to use

  the Shibboleth attribute that should be available after authentication.


How it is implemented by Dataverse:


1. Log in filter implemented on dataverse_template.xhtml is updated to check whether isPassive is enabled.

2. If enabled, it sends an isPassive javascript to the browser.

3. The javascript checks for a session cookie with the initial location, redirects back to shibd for user free login using existing session.

Example redirect URL: https://dv.stage.qdr.org/Shibboleth.sso/Login?target=https%3A%2F%2Fdv.stage.qdr.org%2Fshib.xhtml?isPassive=1


Configuration:


New db boolean setting, :ShibPassiveLoginEnabled, default is false.


Errors:


Throws an error if either condition cannot be met:

1. the user already needs to have a valid session at his Identity Provider and

2. the Discovery Service must be able to "guess" this Identity Provider for the user.


Questions: 

What happens if the first app accepts less or different attributes than Dataverse? Any corrupted user records?

Any hacking potential? (Is lazy session configured?)


 

Alexander Ivanov

unread,
Apr 14, 2017, 1:13:07 AM4/14/17
to dataverse...@googlegroups.com, Philip Durbin
Hi Kevin,

I think that your write-up of the problem and the solution is accurate.  


> Can you make a Github commit to add some documentation to the guides on how to use it and can you tell me how I might test this?
Done. I've added a commit with documentation and a comment to the pull request:

> What happens if the first app accepts less or different attributes than Dataverse? Any corrupted user records?
This is not a question about Shibboleth passive login but a broader question about Shibboleth SSO login in general.  The effect from using passive login will be the same as that from using direct Shibboleth login.  The question then is: If two applications are configured for Single Sign On with Shibboleth, how do you handle the IdP/SP configuration for these applications if they require different attributes?

You can configure the specific attributes that are released to each SP by modifying attribute-filter.xml in the IdP configuration.  Distinct AttributeFilterPolicy elements can be defined for the different applications.  There should be no corrupted user records because the IdP will not be merely re-sending the same attributes to the second application.. it will be sending the correct attributes that are specified for that SP.  I just tested this on our Stage server and it works as expected- distinct attributes can be sent to the different SPs and this works with passive authentication.

> Any hacking potential? (Is lazy session configured?)
It is difficult for me to say how secure Shibboleth passive login is vs. Shibboleth direct login.  I can say that Scott Cantor, one of the chief developers behind Shibboleth, suggested that I use the isPassive feature for our SSO configuration:
I'm not sure what you mean by Is lazy session configured?


My Best,
Alex


--
You received this message because you are subscribed to a topic in the Google Groups "Dataverse Users Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dataverse-community/Fc0wC4fLyeI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dataverse-community+unsub...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/9c4f58cb-c68c-4a29-bca9-a1ab776ef050%40googlegroups.com.

Condon, Kevin M

unread,
Apr 14, 2017, 11:08:25 AM4/14/17
to dataverse...@googlegroups.com, Durbin, Philip
>I think that your write-up of the problem and the solution is accurate.  

Great, thanks.

> Can you make a Github commit to add some documentation to the guides on how to use it and can you tell me how I might test this?
Done. I've added a commit with documentation and a comment to the pull request:

Thanks, it looks good.

> What happens if the first app accepts less or different attributes than Dataverse? Any corrupted user records?
This is not a question about Shibboleth passive login but a broader question about Shibboleth SSO login in general.  The effect from using passive login will be the same as that from using direct Shibboleth login.  The question then is: If two applications are configured for Single Sign On with Shibboleth, how do you handle the IdP/SP configuration for these applications if they require different attributes?

>You can configure the specific attributes that are released to each SP by modifying attribute-filter.xml in the IdP configuration.  Distinct AttributeFilterPolicy elements can be defined for the different applications.  There should be no corrupted user records because the IdP will not be merely re-sending the same attributes to the second application.. it will be sending the correct attributes that are specified for that SP.  I just tested this on our Stage server and it works as expected- distinct attributes can be sent to the different SPs and this works with passive authentication.

Fair enough, if the mechanism for creating the session at the Dataverse end is the same, then yes it is the same as pressing the log in button for Shib. My question stems from support experiences we've had with our instance being part of a federation where all IdPs do not share the same attributes. We do handle those situations where required attributes are not present with an error page to the user identifying what is missing. Given your assessment, this does not alter the current situation -we'll still handle required attributes as usual.

> Any hacking potential? (Is lazy session configured?)
> It is difficult for me to say how secure Shibboleth passive login is vs. Shibboleth direct login.  I can say that Scott Cantor, one of the chief developers behind Shibboleth, suggested that I use the isPassive feature for our SSO configuration:
I'm not sure what you mean by Is lazy session configured?

Thanks, I skimmed it initially but will reread. I agree Scott Cantor is a credible source 😉

Oh, I was referring to a note in the Shib docs: 
"Make sure #THIS PAGE# is protected with a lazy session (no Shibboleth session is enforced but attribute are made available to application in case a user has a session)"

There is a page on its meaning:

I'm not an expert in this area, just reading through the docs, making sense of things as I go. This may be a non issue -just the author trying to be complete in their technical description. I think all they are saying in the isPassive page is in the case of isPassive, to make sure the page has access to the attribs so it can decide whether to allow the user access to it.

Kevin

Condon, Kevin M

unread,
Apr 14, 2017, 1:23:29 PM4/14/17
to dataverse...@googlegroups.com, Durbin, Philip


OK, this has been merged. Thanks for the contribution and explanation.


Kevin


Reply all
Reply to author
Forward
0 new messages