UI/UX for Shibboleth login

[pdurbin]

This morning @mheppler and I talked about what the login might look like for Shibboleth users. I showed him the simple Embedded Discovery Service (EDS) "picker" from the Shibboleth project I installed on a test server that allows me to enumerate IdPs for users to be able to choose from. Currently, the only choices are the Identity Provider (IdP) from http://testshib.org and a test IdP from Harvard.

In reality it's much more likely that rather than hard-coding a list of Shibboleth IdPs, we will dynamically pull an approved list from http://www.incommon.org/participants/ for US Institutions and other lists (?) for non-US. http://www.hathitrust.org for example, seems to pull from a long list of US institutions but http://www.hathitrust.org/shibboleth indicates they support some institutions in Spain. If you click the login link from http://dataverse.nl you'll see a searchable list of Dutch universities. In the Shibboleth world, you see the acronym WAFY for "Where Are You From" for this process.

We plan to have a design meeting for all the UX/UI for Shibboleth login and will be taking notes here: https://docs.google.com/a/harvard.edu/document/d/14VkVa9hJftwVEgMkC7314m0alUwwIHCBJokgGYO1Ra8/edit?usp=sharing

[bencomp]

I'm not too knowledgeable about the workings of Shibboleth and the implementation at SURFnet (called SURFconext), but I am pretty sure SURFconext acts as an IdP on behalf of the universities and other connected organisations. It means we only have to ask the network participants to flip the switch to allow us using the SAML attributes. There is more administration involved between us, the SP, and the source IdPs, but it's been in production for years. It looks like SURFconext is our Centralized Discovery Service - though I don't know if they use this particular software.

[akio-sone]

Just FYI about "Solutions for IdP Discovery" by DASISH (Digital Services Infrastructure for Social Sciences and Humanities):
http://training.dasish.eu/training/2/4/8.html

[akio-sone]

Phil,
just FYI about a sample SSO project based on Spring Security SAML:

// Project
https://github.com/spring-projects/spring-security-saml/tree/master/sample

// Documentation
http://docs.spring.io/spring-security-saml/docs/1.0.x-SNAPSHOT/reference/htmlsingle/#sample-app

On 8/1/2014 12:02 PM, Philip Durbin wrote:

This morning @mheppler https://github.com/mheppler and I talked about
what the login might look like for Shibboleth users. I showed him the
simple Embedded Discovery Service (EDS) "picker" from the Shibboleth
project
https://shibboleth.net/products/embedded-discovery-service.html I
installed on a test server that allows me to enumerate IdPs for users to
be able to choose from. Currently, the only choices are the Identity
Provider (IdP) from http://testshib.org and a test IdP from Harvard.

In reality it's much more likely that rather than hard-coding a list of
Shibboleth IdPs, we will dynamically pull an approved list from
http://www.incommon.org/participants/ for US Institutions and other
lists (?) for non-US. http://www.hathitrust.org for example, seems to
pull from a long list of US institutions. If you click the login link
from http://dataverse.nl you'll see a searchable list of Dutch
universities. In the Shibboleth world, you see the acronym WAFY for
"Where Are You From" for this process.

We plan to have a design meeting for all the UX/UI for Shibboleth login
and will be taking notes here:
https://docs.google.com/a/harvard.edu/document/d/14VkVa9hJftwVEgMkC7314m0alUwwIHCBJokgGYO1Ra8/edit?usp=sharing

—
Reply to this email directly or view it on GitHub
#794.

Akio Sone
Odum Inst.
UNC at Chapel Hill

[akio-sone]

Hi all,
just FYI about WAYF GUI examples of the University of North Carolina
Identity Federation:

// documentation
https://federation.northcarolina.edu/federation/metadata.htm

esp. see the section of "Visual Customization"

• dropdown

https://federation.northcarolina.edu/wayf/index.php?fed=FED_SHIB_UNC_PROD&version=dropdown

• images

https://federation.northcarolina.edu/wayf/index.php?fed=FED_SHIB_UNC_PROD&version=images

On 8/1/2014 12:02 PM, Philip Durbin wrote:

This morning @mheppler https://github.com/mheppler and I talked about
what the login might look like for Shibboleth users. I showed him the
simple Embedded Discovery Service (EDS) "picker" from the Shibboleth
project
https://shibboleth.net/products/embedded-discovery-service.html I
installed on a test server that allows me to enumerate IdPs for users to
be able to choose from. Currently, the only choices are the Identity
Provider (IdP) from http://testshib.org and a test IdP from Harvard.

In reality it's much more likely that rather than hard-coding a list of
Shibboleth IdPs, we will dynamically pull an approved list from
http://www.incommon.org/participants/ for US Institutions and other
lists (?) for non-US. http://www.hathitrust.org for example, seems to
pull from a long list of US institutions. If you click the login link
from http://dataverse.nl you'll see a searchable list of Dutch
universities. In the Shibboleth world, you see the acronym WAFY for
"Where Are You From" for this process.

We plan to have a design meeting for all the UX/UI for Shibboleth login
and will be taking notes here:
https://docs.google.com/a/harvard.edu/document/d/14VkVa9hJftwVEgMkC7314m0alUwwIHCBJokgGYO1Ra8/edit?usp=sharing

—
Reply to this email directly or view it on GitHub
#794.

Akio Sone
Odum Inst.
UNC at Chapel Hill

[pdurbin]

https://federation.northcarolina.edu/wayf/index.php?fed=FED_SHIB_UNC_PROD&version=images

Nice! I like the images. Thanks, @akio-sone!

[pdurbin]

We plan to have a design meeting for all the UX/UI for Shibboleth login and will be taking notes here: https://docs.google.com/a/harvard.edu/document/d/14VkVa9hJftwVEgMkC7314m0alUwwIHCBJokgGYO1Ra8/edit?usp=sharing

Ok, we just had a design meeting and that Google Doc is now full of notes.

[pdurbin]

@mheppler and @eaquigley I wanted to remind you of the related "Make it clear at signup that display names for users will be searchable" ticket at #749.

[pdurbin]

I just found an interesting "picker" at http://cdn.discojuice.org/discovery via http://discojuice.org/getting-started/#whatis via https://wiki.univie.ac.at/display/federation/Discovery+Services via http://shibboleth.1660669.n2.nabble.com/Centralized-Discovery-Service-The-Discovery-Service-should-not-be-called-directly-tp7604250p7604280.html

Screenshot attached.

[pdurbin]

I really like the advice at http://discovery.refeds.org

• Good Practice Guide: http://discovery.refeds.org/guide/
• Good Discovery Demo: http://discovery.refeds.org/demo/good/
• Bad Discovery Demo: http://discovery.refeds.org/demo/bad/

As far as specific software to use, they have this to say:

If you are offering services to academic institutions, it is likely that they will be using SAML. NISO ESPRESSO recommends that you use either the DiscoJuice or Shibboleth EDS software to support external login for these customers. Both of these products offer the benefits described above.

EDS ( https://shibboleth.net/products/embedded-discovery-service.html ) is what I've been demo'ing at https://apitest.dataverse.org and was first suggested to me in INC00953080. So far I've only used a hard-coded list of IdPs with it (TestShib and Harvard). We've been playing with the RPM version (shibboleth-embedded-ds-1.0.2-2.2.noarch), but here's the latest: http://shibboleth.net/downloads/embedded-discovery-service/latest/

[esotiri]

Phil this looks great.

I like this one too https://vho.aaf.edu.au/
http://aaf.edu.au/services/international-federations/

Login into the virtual home dashboard, they have mixed drop down and search, and you can see/choose the organization at the drop down, but at the same time you can filter.

[pdurbin]

So far I've only used a hard-coded list of IdPs with it (TestShib and Harvard).

I played around with EDS a bit more and loaded up a long list of institutions based on XML from https://spaces.internet2.edu/display/InCFederation/Metadata+Aggregates

Here's how it looks on https://apitest.dataverse.org

Note that the three most recent selections are remembered and put at the top as explained at http://discovery.refeds.org/demo/good/step-three/

The screenshot also shows the filtering that can be done.

These are mostly American universities and colleges. We'd need to figure out what federations are out there and how best to pull the latest metadata for each country (or however these federations are organized).

Another next step for EDS is figuring how how to put the picker right on the login page (next to local login) rather than having a separate page.

[pdurbin]

@mheppler can you please take a look at the auth branch? With everything fully set up in Vagrant and re-configured not to use my pagekite, I expect you to see something like this the screenshot below.

[pdurbin]

@mheppler I worked on the GUI a bit more (still need help, obviously) but it now looks a little closer to the mockup at https://iqssharvard.mybalsamiq.com/projects/loginwithshibboleth/Login (screenshot attached).

Please note that this required upgrading to a pre-release version of Shibboleth Embedded Discovery Service (EDS) as noted in the showListFirst (EDS v1.1.0 and later) thread I started on the Shibboleth mailing list.

Notes that EDS stores a cookie to remember up to three previous selections.

[bencomp]

@pdurbin looks good!

[pdurbin]

There's still more I'd like to do with Shibboleth, especially reworking the back-end and moving the code into ShibAuthenticationProvider but I'll try to chat with @michbarsinai about this at JavaOne and will probably work on that in #791.

For the next beta push, the UX seems to be more or less what we want. We now show a Terms of Use page (see also #878). (If you log in with the TestShib IdP you always see the TOS page because we create a new user ever time, as I explained to @esotiri .)

@mheppler I know you have this ticket now but I think the UI is good enough. I'm going to pass it QA.

[kcondon]

This ticket represents an initial step in the delivery of Shibboleth and will be used to learn more from users and IdPs about practical issues that may affect design.

After speaking with Phil, this is my understanding of what functionality will be delivered. This does not reflect the full design intention for this feature and the UI component requirements have not been reviewed for this deliverable.

Features:

1. HTTPS is required
2. Whether Shibboleth log in is available is configurable through an api call/ db setting.
3. The list of available IdPs for log in is configurable through a local xml file.
4. For the purpose of the demo site, only TestShib is initially supported as the IdP and that supports only 3 static user accounts. We plan to invite Shibboleth users to work with us to add their IdPs for testing purposes.
5. Shibboleth users will be treated like real users in terms of creating/editing/deleting objects like dataverses, datasets, files, but cannot change their personal account information from Dataverse, only at their IdP.
6. Terms of Use is always shown to TestShib users at each log in but only once to "real"/ other IdPs. This is because there are 3 static TestShib users that are shared by everyone so displaying once does not make sense.
7. Each TestShib log in is a new identified user behind the scenes so that shared users do not see other's content. The side effect is that once they close their browser, they can never get back to their test data as a TestShib user. This is a "hack" to make the shared accounts on TestShib useful. For a real Shib IdP, it would act like a normal/returning user. Note that log out/in still can access data, only closing browser will destroy session info.
8. A Shib user's name is presented in the upper right corner like a local user except when those attributes are not available from the server, in which case it says, "unknown". It was suggested that instead it say something like "TestShib User" or User and a rollover indicate that no name info was supplied.
9. There is also a feature to disable sign up using an API call and is a database setting.

[michbarsinai]

Phil will probably add more, but here are my notes:

1. Shibboleth users will be treated like real users in terms of creating/editing/deleting objects like dataverses, datasets, files, but cannot change their personal account information.

They can - they should do it on their Shibboleth server. This way, they can update their info in a single place. When a shibboleth user logs in with updated data, their local data is updated.
7. Each TestShib log in is a new local user behind the scenes so that shared users do not see other's content. The side effect is that once they close their browser, they can never get back to their test data as a TestShib user. This is a "hack" to make the shared accounts on TestShib useful. For a real Shib IdP, it would act like a normal/returning user. Note that log out/in still can access data, only closing browser will destroy session info.

Not a "local user", an "Identified User". Local users are users from an idp that just happened to be bundled with Dataverse, for all the system cares. When a local user is created, a corresponding Identified User is created as well.

Also, in this release we have options to disable sign up (ODUM wanted this), and to direct users to a specified sign up page (e.g. go register at your department's LDAP server).

-- Michael

On 7 Oct, 2014, at 11:01 PM, kcondon notifications@github.com wrote:

This ticket represents an initial step in the delivery of Shibboleth and will be used to learn more from users and IdPs about practical issues that may affect design.

After speaking with Phil, this is my understanding of what functionality will be delivered. This does not reflect the full design intention for this feature and the UI component requirements have not been reviewed for this deliverable.

Features:

1. HTTPS is required
2. Whether Shibboleth log in is available is configurable
3. The list of available IdPs for log in is configurable through a local xml file.
4. For the purpose of the demo site, only TestShib is supported as the IdP and that supports only 3 static user accounts.
5. Shibboleth users will be treated like real users in terms of creating/editing/deleting objects like dataverses, datasets, files, but cannot change their personal account information.
6. Terms of Use is always shown to TestShib users at each log in but only once to "real"/ other IdPs. This is because there are 3 static TestShib users that are shared by everyone so displaying once does not make sense.
7. Each TestShib log in is a new local user behind the scenes so that shared users do not see other's content. The side effect is that once they close their browser, they can never get back to their test data as a TestShib user. This is a "hack" to make the shared accounts on TestShib useful. For a real Shib IdP, it would act like a normal/returning user. Note that log out/in still can access data, only closing browser will destroy session info.

—
Reply to this email directly or view it on GitHub.

[kcondon]

tested works