Assumptions (the system will be replicated in all DAC instances.):
- User has been authenticated by logging in to LSST, using identity management provided in NCSA
- User has an account in LSST system
Related products:
- Resource management (NCSA)
- A+A (NCSA)
Question:
- I assume that the content for user workspace will not be duplicated at different DAC. Do we allow one user to have workspace at both US and Chile? If yes, how do we manage resources for the user?
Capabilities in User Management System:
- Identity mapping between the login-ID and LSST-ID
CILogon service provides authentication service, allowing user to login with institute ID, Google ID, or GitHub credentials, just to name a few. After user authentication, LSST applications need to know the user's LSST-ID so the applications can access the authorization system for privileges for this user.
When a user logs in with different credentials (GitHub, Google, institution ...), the system should be able to map either one to the correct LSST-ID.
- Content of the user management system
- contact information:
- user name, address, phone number, email, institute
contact preferences (like subscribe to list of newsletter ...)
group information: group names the user belongs to
group information:
group name, admin for the group, users in the group
data access info for the group
- information regarding data rights: right to search, to view, to download.
- Table access granularity: release level, table level or row level
- File system access granularity: directory, file
- when a user loses the data right at time A, but still has access to data produced/released before time A, the system needs to have capability to distinguish this.
- Information related to resources:
- User workspace: DAC, root directory, disk usage and quota,
- User database: name, database server, database usage and quota,
- Computation: CPU usage and quota,
- Alert subscription database:
- Access control information:
- Sharing with other users
- Collaboration group sharing
- User preference in Portal and Notebook
- First question: Shall we save the user preference in the central user management system, or Portal/Notebook keeps its own?
- For portal, some of the preferences are mainly meaningful in portal, but some could be shared with Notebook, like search history.
- search history, ...
- Table data display: table page size, selected columns, sorting (asc, desc) preference,
- Image display: preferred stretch, distance unit, default zoom level, coordinate system and format for position readout, coordinate grid overlay on images, color preference for catalog overlay, ...
- XY plot display: columns as X, Y axis,
- For Notebook ....
- contact information:
Administration of the User Management System
- Self service by users
- contact information update
- password retrieval/reset
- create a group and manage membership in the group
- grant permission to other user and/or group to access my workspace (read/write/execute)
- can a user merge two accounts created by accident? But more importantly, how do we prevent a user to create multiple accounts to get more resources?
API to access the user management system
- login API should take redirect URL after successful login
- Token granted after successful login:
- Life duration of the token
Background information:
From LDM-542 2.2.7 Data Access Permissions and Quotas
"Users who had LSST data rights but have since lost them may be granted access to the data products available as of the time of loss but not newer ones."
6 Comments
Frossie Economou
Thanks for doing this XiuQin. I suggest calling out explicitly the need for a user to self-service any changes to their own information (eg. changes in email address) and (although I assume this will be handled in NCSA's identity management system) able to reset their password.
For what it's worth, users in the wild are not able to disambiguate between various layers of authentication - to them it's all going to be their "LSST ID" whether it is underwritten by an NCSA system or not, so I think it's important for the user experience to "look" like a single unified LSST process.
Minor point but some kind of contact preferences ("subscribe to our newsletter" type of thing) would be nice.
The other tricky thing that often comes up is the ability to merge accounts. I was in Cambridge and had an LSST account, now I moved, and I forgot I had one, so I create a new one, only oh wait, I now remember I had this date under my old one, etc etc.
Donald Petravick
has this page been shared with Basney?
Joel Plutchak
I sent the link to Doug, since he is tracking work on Identity Management at NCSA. I'll send to Basney.
Brian Van Klaveren
I think a core functionality of the User Management Service we'd like is for users to discover the roles and/or groups a user is a member of, either using a (delegated) token, which a service has acquired, or by allowing third party services. This functionality may be needed for IVOA standards in the future (Group Membership Service: http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-GWS/GMS-Specification.pdf). It may also be used by science collaborations to produce their own data portals based on LSST user management system, and finally, it might be necessary for Jupyter/VOSpace stuff to really work properly.
Donald Petravick
so, there was a requirements process, that ran extensively about a year or so ago, and we actually have an "as is" system, and a program of work to satisfy the results of the process. I'd say it's up to Jim/Doug at NCSA to understand if a request like Brian's is consistent with what is not enshrined in a plan, and what should be done if the plan does not satisfy the need.
Jeff Kantor
+1 and I think this entire team should be able to see that plan as documented, is there a link? I have seen and reviewed an Identity Management Phase I plan/SOW, but that is only the first part of it.
I have been tasked by Victor to be the Project Office liaison for this work, so I need to understand scope of work and associated cost/budget for the entire package.