Notes about the infrastructure and design of user accounts for inspire

SLAC Computing will (probably) not mind creating a lightweight (lw) account here for this service. Trying to integrate with local (NICE/AFS/etc) accounts may prove to be too difficult, but now I'm wondering about these possible solutions:

Separate Accounts

• Inspire accounts are completely separate from any other account (CERN lw, lab accounts, etc)
• No other accounts are used (though of course CDS users can migrate)
• I.e. this is the out of box solution that looks like yahoo etc.

Pros

• Simple, in that this is the same way yahoo, facebook etc all work, most users are used to this
• Simple in that invenio comes with this out of the box

Cons

• Extra maint. in that we must maintain accounts (does CDS do this already? how much FTE?)
  • Tibor/2008-05-07: CDS uses central CERN accounts and groups, so we don't see any overhead here. In the past, when we have been using local accounts, there were something like 30-50 automatic password reminder emails per month, which could give you an idea. This was fully automatic though, without us having to do anything. As for the account-related questions we had to solve manually, I would estimate their number to be around 5-10 per month (and less now with central accounts). Some of these questions are: (a) I would like to unsub from an alert; (b) my colleague has left and I don't have rights to revise this fulltext; (c) spokesperson has changed etc. The problems are more of the submission nature than of the basket/alert nature. To sum up, a local account database is not too much of a problem to maintain. A much bigger issue would be to maintain local user groups if we cannot easily access and reuse existing groupware facilities (mailing lists, LDAP, etc).
• Ignores much existing authentication infrastructure within HEP (Existing Lab accounts, grid, Hepnames, arXiv, etc)
• Above point is especially important regarding group memberships etc. Would be very nice to share baskets with all members of locally defined research groups

Lab accounts + lightweight

• SLAC lw accounts + CERN lw accounts with all 4 mirror sites also enabling their own lab login accounts on their own mirror
• The user would go to the main server (probably at SLAC, underneath a hepinspire.org url)
  • When user clicks "login" they get a dropdown with several account types (CERN lw, SLAC lw, CERN real, SLAC real, FNAL real, DESY real, etc)
    • May not want to distinguish between real and lw for labs that have both...
  • Choosing a lab from dropdown sends the user to the correct mirror site, so each account belongs to a specific mirror.
  • Once on the mirror site, the user stays there, with their session logged in etc.

Pros

• Takes into account some existing infrastructure
• Might imagine that this could start to map local lab groups to inspire (share my baskets with AFS group...etc)
• Helps create mirroring that makes sense somewhat (can't move from site to site, but account takes users to the right site naturally, has some nice PR aspects in that every lab is visible in some way) but is relatively simple to accomplish

Cons

• Complex for users (i.e. did I create two acconts? Which account works here?)
• Complex to administer for us, in that user account requests could potentially span several infrastructures.

Grid Certs

• I cannot adequately explain the exact ways in which these certs would be made to work in the context of browser auth. Perhaps someone can add things here?
  • Tibor/2008-05-07: Certificates are fully supported by Invenio as soon as we use the Apache Shibboleth and the Single Sign-On authentication method. (Beware, SSO must be the unique auth method, so we cannot use more auth methods alongside SSO.) You can test the certificate-powered access live on CDSWEBDEV development machine (accessible only from inside CERN though). For some hints on how we set up Invenio and SSO, see the InvenioShibbolethSSO wiki page.
• Can be combined with above solution, but only with some work establishing mirror servers with different auth. schemes (this may need to be done anyway for lab accounts, or admin accounts, or..)

Pros

• Computing groups at both SLAC and CERN (others) are interested in moving in this direction for inspire and many other things of course
• Using existing infrastructure
• simple to maintain ( not in our hands)

Cons

• Complex for users...overly so for needs of inspire alone
• Many users not in experiments/labs/etc. and would have no other reason to get grid certs.
• Integration with browser not (yet) simple

Opinion:

I think the simple, lw account separate solution is quite nice. However, enabling grid certs as well in some way might be a nice future enhancement. Trying to tie together regular lab accounts seems overly complicated.

For the alpha, if anything, we should create (lightweight) accounts ourselves for chosen testers, if we enable any account features for alpha.

Admin Accounts (separate issue)

SLAC computing would like admin accounts to be handled separately. We can do this in one of two ways

1) Disable the web admin account for the public site, manage it entirely through the backend. All enrichment would be done via a separate server to the same backend MySQL database accessible only to admin-level accoutns (or possibly all local accounts at SLAC...?) Since all metadata updates would go via the second server, the main server becomes a read-only close for the purposes of all metadata. User-generated content from rankings, downloads, etc would flow the other direection, but we are already dealing with that.

2) admin level accoutns are also separate from individual lab accounts. This is a bit annoying, in some ways, and I'm not sure what computing here will think about this...but it is far simpler. However, option one has the nice advantage that things don't slow down while bibindex is running, etc etc.

-- TravisBrooks - 29 Mar 2008