Shibboleth model of Service Providers (SPs) and Identity Providers (IdPs) (a follow up to the IRC)

[marlen...@gmail.com]

Hi all,

I sent the message below to Phil Durbin following the IRC Chat of Feb 13.

It most importantly covers the Shibboleth model of IdPs (and SPs.  The Shib design center is a bit different from what some people on the call were assuming, so I wanted to provide clarification. 

I also discuss providing local login along with Shib authentication, and the idea of building your own SP.

Phil suggested I post the message here.  So, belatedly, that's what I'm doing (below my signature).

Thx,
Marlena Erdos (one of the co-creators of the original Shibboleth and SAML specs)

Hi Phil,

I hope you found my participation in today's IRC chat useful.

I wanted to go over some high points (as I recall them):

I clarified that an SP doesn't need (or even have) a "home" IdP.   The user has a home institution and IdP, but that's entirely distinct.   The design center of SAML and Shibboleth is that of an SP having relationships and accepting  assertions about users from multiple IdPs/institutions.

I also brought up two possibilities for dealing with users who don't have an IdP at their home institution.  The first is to offer "local login" on the "where are you from page" you'll need to put up when  user first contacts the Dataverse.   The second is to tell users to get a login from "ProtectNet" or another free IdP.  Seeing as you don't do identity proofing of users, I don't see a security difference between a user logging in via ProtectNet and logging in via a local identity and password that the Dataverse is storing.   The advantage to going to an "all IdP" solution is uniformity of user experience -- and that the Dataverse gets out of the business of password management.

I noted that you are considering building your own SP to avoid a dependency on apache httpd (and presumably also IIS).   I merely want to mention that you should keep in mind that the InCommon SP offers rich attribute handling facilities.  You might not need them now but you might want them in the future.  I'll also note that you'll need to leave time in your schedule for interoperatibility testing if you build your own SP.  And you'll need to keep up with developments with the InCommon IdP.  All of this might be "easy" -- I can't tell.  I thought it was worth mentioning.

Thanks,
Marlena

[Philip Durbin]

Thanks, Marlena. Much appreciated.

Writing a custom SAML Service Provider (SP) within DVN would be a last
resort, I think. I listed it last at
https://redmine.hmdc.harvard.edu/issues/2657#note-3 . Mostly this idea
came from a conversation I had in #glassfish on Freenode:
http://www.evanchooly.com/logs/%23glassfish/2013-02-07

Per that Redmine update, OpenAM is what I'm planning to try first
(after I work more on a different project: Solr). OpenAM seems
especially nice because it supports not only SAML but 18 other
"modules" such as OAuth, LDAP, RADIUS, etc.:
http://lists.forgerock.org/pipermail/openam/2013-February/010583.html

SAML support in OpenAM comes from the "Federation" module:
http://openam.forgerock.org/openam-documentation/openam-doc-source/doc/admin-guide/index/chap-federation.html

In short, the hope would be that OpenAM provides a flexible framework
to support multiple authentication methods. Time will tell how it pans
out. Their mailing list is very responsive!

Also, thanks for pointing out that accounts at
http://www.protectnetwork.org are free. I didn't realize that.

Phil

> --
> 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-commu...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Philip Durbin
Software Developer for http://thedata.org
http://www.iq.harvard.edu/people/philip-durbin