The Ticket Formerly Known as Log In & Shibboleth: Onboarding Process

[eaquigley]

Due to passwords needing to be changed and Shibboleth account conversions, we need a robust, interactive, and helpful onboarding process to let users know how their accounts need to be updated.

[raprasad]

\cc @scolapasta @eaquigley @pdurbin
(... Summary of my memory on the username issues. Some of it may have changed in last few months)

What happens when an existing Harvard user wants to use Shibboleth? (local account -> shib account)

summary: User loses her/his username. User no longer has separate first/last name fields

• Currently, if existing Dataverse users are migrated to Shibboleth (or other outside authentication), they will lose their Dataverse Usernames. For account migration, the process may be made easier by allowing users to keep their existing usernames.
• In general, requiring Usernames for one type of authenticated user but not another leads to inconsistencies. It may make it harder to transition users from one type of authentication to another.

What happens when a User leaves Harvard? (shib account -> local account)

summary: User be assigned a brand new username. User's first and last name fields will be combined into one field

• Although not relevant immediately, having a Username for all authenticated users will help when trying to migrate users off of Shibboleth (or other institution-dependent authentication.)
• In the case of a scholar who accesses Dataverse via Shibboleth and is leaving Harvard, the existence of a Username from the beginning would make migration to a local account much easier.

Not storing First name, Last name for Shibboleth users

• Only local Dataverse account holders have separate first and last names stored in the database. Shibboleth users, and other outside authenticated users, have only a “Display Name” stored in the database.
• Currently, first and last name would be lost if moving to shibboleth from a local account
  • Shibboleth Users: Display Name
  • Local Account Users: Display Name, First Name, Last Name

Given that first and last name information is available via Shibboleth (and other known authentication systems), it seems to make sense to store this data. In this way, the name of a user may be displayed in “FirstName LastName” format, or “LastName, FirstName” format, as appropriate.

[pdurbin]

@eaquigley this ticket seems to be a duplicate of #796 which says, "This ticket is about the UI/UX for the conversion."

[raprasad]

(Following up on above)

Potentially problematic Novel storage of User and Group Keys

Within Postgres, role assignments within the permissions system do not use traditional relational database keys, such as integers. Instead, user and group identifiers are referenced as follows:

• Table: roleassignment
• Column: assigneeidentifier (not a ForeignKey)
  • User format: @Identifier.
    • Example assigneeidentifier values in db: @pete, @uma
  • Group format: &identifier.
    • Example assigneeidentifier values in db: `&1, &2``

The “@” and “&” symbols are used to distinguish between users and groups. More traditional models would use either separate tables for users and groups or a “type” column to distinguish between the two.

The use of Usernames, in the cases of @pete and @Uma, may become problematic if those users are migrated to shibboleth or vice versa.

(Use of the "authenticateduserlookup" table clarified by @michbarsinai. “assigneeidentifier” strings persist after user migrated)

[mheppler]

I'm just going to leave this here, with hopes that sanity will reign and we implement what we first designed for this workflow.

https://iqssharvard.mybalsamiq.com/projects/loginwithshibboleth/Dataverse%20Account%20II%20-%20Choose%20Username

[pdurbin]

Example assigneeidentifier values in db: @pete, @Uma

See also the "Stop using @pete and @uma (strings) in role assignments" ticket: #1151

[michbarsinai]

Discussion was moved to email. (TL;DR: either This ticket can be closed, or someone gets a Turing award :-) )

Sent from my iPhone

On 30 בינו׳ 2015, at 18:47, Raman Prasad notifications@github.com wrote:

(Following up on above)

Potentially problematic storage of User and Group Keys

Within Postgres, role assignments within the permissions system do not use traditional relational database keys, such as integers. Instead, user and group identifiers are referenced as follows:

Table: roleassignment
Column: assigneeidentifier (not a ForeignKey)
User format: @Identifier.
Example assigneeidentifier values in db: @pete, @Uma
Group format: &identifier.
Example assigneeidentifier values in db: &1, &2`
The “@” and “&” symbols are used to distinguish between users and groups. More traditional models would use either separate tables for users and groups or a “type” column to distinguish between the two.

The use of Usernames, in the cases of @pete and @Uma, may become problematic if those users are migrated to shibboleth or vice versa.

(Use of the "authenticateduserlookup" table clarified by @michbarsinai. “assigneeidentifier” string persist after user migrated)

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

[pdurbin]

either This ticket can be closed, or someone gets a Turing award

I wouldn't say that. A significant amount of refactoring work has been proposed: #1151 (comment)

That's my understanding, anyway.

[eaquigley]

As mentioned during the weekly team meeting yesterday, this ticket is more about making sure users can tell the differences between logging in with a built in account and logging in with Shibboleth NOT about all the technical details as listed above. That discussion and the decision reached is more of a fit for #1151.

[michbarsinai]

BTW, here's NYT on the revamped twitter on boarding process. Some parts may be applicable for us (but not for Beta 12).
http://bits.blogs.nytimes.com/2015/02/02/twitter-displays-its-value-with-instant-timeline-for-new-users/?_r=1&utm_medium=email&utm_campaign=Versioning http://bits.blogs.nytimes.com/2015/02/02/twitter-displays-its-value-with-instant-timeline-for-new-users/?_r=1&utm_medium=email&utm_campaign=Versioning

On Feb 3, 2015, at 22:14, Elizabeth Quigley notifications@github.com wrote:

As mentioned during the weekly team meeting yesterday, this ticket is more about making sure users can tell the differences between logging in with a built in account and logging in with Shibboleth NOT about all the technical details as listed above. That discussion and the decision reached is more of a fit for #1151 #1151.

—
Reply to this email directly or view it on GitHub #1387 (comment).

[eaquigley]

I am closing this ticket and starting a new one about this so these comments aren't deleted.