dvn-auth October 2014

dvn-auth@lists.iq.harvard.edu

1 participants
3 discussions

Shibboleth persistent identifier: persistent-id vs. eppn vs. ePTID vs. NameID

by Philip Durbin

Hello! Question for all you Shibboleth experts out there... If I'd like to take one of the attributes and store in in Dataverse as a persistent identifier? Which one should I use? >From playing around with the IdP at http://testshib.org I assumed "persistent-id" would be the one to use. It looks nice and unique: persistent-id: https://idp.testshib.org/idp/shibboleth!https://apitest.dataverse.org/shibb… However! I'm hearing that "persistent-id" may not be so commonly used... that perhaps in Higher Ed anyway "eppn" might be used instead. The weird thing to me about "eppn", however is that (at least from TestShib) there's a username in it: eppn: myself(a)testshib.org Furthermore, eppn is allowed to change (!) according to https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-… "Values of eduPersonPrincipalName are often, but not required to be, human-friendly, and may change as a result of various business processes. They may also be reassigned after a locally-defined period of dormancy. Applications that require a guarantee of non-reassignment and more stability, but can tolerate values unfriendly (and unknown) to humans should refer to the eduPersonTargetedID attribute." So... maybe we should require eduPersonTargetedID (also known as ePTID) instead... But then I checked in with a non-Higher Ed person, and he uses Assertion -> Subject -> NameID. It looks like this: <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">user1</saml2:NameID> It's got "persistent" in it, which I like. :) >From what I can tell from docs above "[ePTID] is an abstracted version of [NameID]" anyway, so maybe I should just require NameID so non-Higher Ed people aren't confused. Of course, I may just be confusing myself... I hope it's clear what I'm asking... What we need on the Dataverse side is to but something in the "FIXME" below: permanentId = httpServletRequest.getAttribute("FIXME"); Should the "FIXME" be "NameID" perhaps? "eppn"? Something else? Please advise. We'll be using this value to find the Shib users in the system each time they log in. Thanks! Phil p.s. Chats I just had (summarized above): http://irclog.perlgeek.de/shibboleth/2014-07-29 Time Nick Message 19:57 pdurbin hsnopi or rkeene do you use "persistent-id" for anything? 19:59 hsnopi not taht I am specifically aware of. I think it is used to give a user a permenant id but i could be very very wrong 19:59 pdurbin that's how I was thinking I'd use it 19:59 pdurbin but I'm also hearing that eppn is preferred, maybe? 20:00 pdurbin the IdP at http://testshib.org sends both 20:00 hsnopi that is so far out of my league 20:00 pdurbin eppn: myself(a)testshib.org 20:00 pdurbin persistent-id: https://idp.testshib.org/idp/shibboleth!https://apitest.dataverse.org/shibb… 20:01 pdurbin persistent-id seemed "safer" to use... more unique... 20:01 hsnopi i seem to vaguely recall something about eppn going away at soem point. 20:01 pdurbin hmm http://www.evanchooly.com/logs/%2523glassfish/2014-07-29 pdurbin whartung: persistent-id or eppn? whartung pdurbin: eh? pdurbin heh pdurbin whartung: http://irclog.perlgeek.de/shibboleth/2014-07-29 whartung frankly, I don't recognize either of those :) pdurbin whartung: what attribute do you use to uniquely identify a user who has logged in via shibboleth? whartung Subject->NAmeID pdurbin huh pdurbin I'm not used to seeing "->" in an attribute whartung Assertion -> Subject -> NameID pdurbin oh oh whartung no, it's the heirarchy pdurbin whartung: you're giving me the xpath ;) whartung yea pdurbin cool. thanks pdurbin NameID. hmm pdurbin commonly used? whartung Apparently pdurbin ok. eppn comes from higher ed. eduPersonPrincipalName https://www.incommon.org/federation/attributesummary.html whartung ok whartung yea, we're not in that domain whartung generic Response of ours: http://pastie.org/private/oay0trwmvrw9e0haekqmlw pdurbin ok so <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">kayyagari</saml2:NameID> pdurbin interesting whartung right pdurbin so I'm seeing "persistent" there and under "longevity" at https://wiki.shibboleth.net/confluence/display/SHIB2/NameIDAttributes pdurbin "persistent: identifiers which are good for a long period of time (e.g. years) but which the IdP may revoke" whartung yea, perahps we should use "permanent" instead pdurbin right -- Philip Durbin Software Developer for http://dataverse.org http://www.iq.harvard.edu/people/philip-durbin

9 years, 1 month

Fwd: User sessions mixed up when Java app deployed to Glassfish is fronted with Apache httpd

by Philip Durbin

I'm seeing a very strange (and scary!) bug now that we're running fronting Glassfish with Apache at https://dataverse-demo.iq.harvard.edu I've described the bug to the Shibboleth mailing list (initial message below) and there have been some follow up posts: - http://shibboleth.net/pipermail/users/2014-October/017878.html - http://shibboleth.net/pipermail/users/2014-October/017879.html - http://shibboleth.net/pipermail/users/2014-October/017885.html Obviously, we can't ship Shibboleth support with a bug like this. Long time readers of this list know that initially I tried a pure Java solution called OIOSAML but the current approach is to use mod_shib, which requires fronting Glassfish with Apache. If anyone has any ideas what the problem might be, please let me know! Thanks! Phil ---------- Forwarded message ---------- From: Philip Durbin <philip_durbin(a)harvard.edu> Date: Wed, Oct 29, 2014 at 6:47 PM Subject: User sessions mixed up when Java app deployed to Glassfish is fronted with Apache httpd To: Shib Users <users(a)shibboleth.net> By following the Shibboleth wiki*, I'm now fronting my Java application server (Glassfish) with Apache httpd so I can use mod_shib and have Shibboleth attributes passed to my Java application. It works (great!) but now that I've configured our beta site this way I have a new, terrifying problem... Users' sessions are getting mixed up! This is just a demo/beta site but obviously this is a show stopper for us moving forward with mod_shib in production. Even on the demo site I'm tempted to pull Apache httpd out of our setup because I don't want people are looking at the demo site to get scared by suddenly seeing that they are logged in as someone else! We never see this problem when we run only Glassfish. The scrambled user sessions has something to do with introducing Apache httpd into the mix. I sure hope there's a simple fix for this. Let me explain how I've set things up. In my Apache httpd config I have these lines: # don't pass paths used by rApache and TwoRavens to Glassfish ProxyPassMatch ^/RApacheInfo$ ! ProxyPassMatch ^/custom ! ProxyPassMatch ^/rookzelig ! # don't pass paths used by Shibboleth to Glassfish ProxyPassMatch ^/Shibboleth.sso ! ProxyPassMatch ^/shibboleth-ds ! # pass everything else to Glassfish ProxyPass / ajp://localhost:8009/ <Location /shib.xhtml> AuthType shibboleth ShibRequestSetting requireSession 1 require valid-user </Location> RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] To enable AJP communication between Glassfish and Apache httpd I use this command: asadmin create-network-listener --protocol http-listener-1 --listenerport 8009 --jkenabled true jk-connector I'm running on CentOS 6.5 and using httpd-2.2.15 which means I'm using mod_proxy_ajp, as the wiki recommends (rather than mod_jk). I'm running GlassFish Server Open Source Edition 4.0 (build 89). Here's where we are tracking problem on our end: https://github.com/IQSS/dataverse/issues/647 Any advice is welcome! Please tell me what I'm doing wrong! I'm happy to point out relevant bits of the code and config, all of which is on GitHub, but I think the key information is above. Phil * "In the setup described here, requests from browsers are intercepted first by Apache httpd. The Shibboleth SP then checks these requests to enforce authentication requirements. After an assertion is received and a Shibboleth session is established, the SP or Apache httpd can enforce access control rules, or it can just pass attributes to the application. The request is then forwarded to the servlet through the use of the AJP13 protocol. Subsequent requests can leverage the Shibboleth session or a session maintained by the application or servlet container to persist the login." under "Install Shibboleth to protect Java Servlets" at https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPJavaInstall p.s. People reporting similar problems (and how tricky it is to reproduce reliably): - http://jeecookbook.blogspot.com/2013/07/modjk-session-mixed-between-users.h… - http://stackoverflow.com/questions/14731806/session-mix-up-apache-httpd-wit… - http://stackoverflow.com/questions/14845493/spring-security-jsf-hibernate-a… -- Philip Durbin Software Developer for http://dataverse.org http://www.iq.harvard.edu/people/philip-durbin -- Philip Durbin Software Developer for http://dataverse.org http://www.iq.harvard.edu/people/philip-durbin

9 years, 5 months

Fwd: [Dataverse-Users] Try out Single Sign-On With Shibboleth in 4.0 Beta

by Philip Durbin

I'm looking for institutions with Shibboleth Identity Providers to test interoperability to the code we pushed to https://dataverse-demo.iq.harvard.edu last night per the announcement below. Right now we only have the TestShib IdP but I'd love to have Odum/UNC, DANS, Duke, etc. as options. Can we exchange metadata? Phil ---------- Forwarded message ---------- From: Eleni Castro <posixeleni(a)gmail.com> Date: Thu, Oct 9, 2014 at 12:52 PM Subject: [Dataverse-Users] Try out Single Sign-On With Shibboleth in 4.0 Beta To: dataverse-community(a)googlegroups.com Greetings Dataverse Community, Dataverse 4.0 Beta <http://dataverse-demo.iq.harvard.edu/> now supports single sign-on using Shibboleth <https://shibboleth.net/>, which allows users to authenticate using the same login credentials that they use for their institution or organization! To test this out in Dataverse 4.0 Beta, select Log In on the top navigation bar. Once on the Log In page under “Institution Log In”, click on “Please select your institution…” dropdown option and select “TestShib Test IdP” and click on the “Continue” button. Next, you will be presented with a login page. As of this blog post, you can only log in with three mock accounts (myself, superego, and alterego) provided by the Identity Provider at http://testshib.org but we are very interested in interoperability testing as many Identity Providers as possible! If the login is successful, you will then be taken to our Dataverse Account Creation Terms of Use page. Please note that these terms are just for testing and demonstration purposes and so are not our actual Dataverse Terms of Use. We are currently working with the Berkman Center <http://cyber.law.harvard.edu/> to update our Account Creation Terms of Use for 4.0. If you run a Shibboleth Identity Provider, you can download the the Dataverse demo Service Provider metadata at https://dataverse-demo.iq.harvard.edu/Shibboleth.sso/Metadata and send your Identity Provider metadata to us via support(a)dataverse.org We would love to be able to have as many institutions able to use Shibboleth when Dataverse 4.0 goes live so please get in touch with us if you are interested! If you are interested in authentication beyond Shibboleth (OAuth, LDAP, etc.), please consider subscribing to our dedicated "dvn-auth" mailing list at https://lists.iq.harvard.edu/mailman/listinfo/dvn-auth Shibboleth is an oft-discussed topic <http://irclog.iq.harvard.edu/search.pl?channel=dataverse&q=shibboleth> in the #dataverse IRC channel on freenode <http://webchat.freenode.net/?channels=dataverse> as well! *Reposted from the Data Science Blog: **http://datascience.iq.harvard.edu/blog/try-out-single-sign-shibboleth-40-beta <http://datascience.iq.harvard.edu/blog/try-out-single-sign-shibboleth-40-be…>* -- 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+unsubscribe(a)googlegroups.com. To post to this group, send email to dataverse-community(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/54796b3e-3296-46e9-94… <https://groups.google.com/d/msgid/dataverse-community/54796b3e-3296-46e9-94…> . For more options, visit https://groups.google.com/d/optout. -- Philip Durbin Software Developer for http://dataverse.org <http://thedata.org> http://www.iq.harvard.edu/people/philip-durbin

9 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

dvn-auth October 2014