PAWS Meeting 2006-10-30
Discussion of Central Login for PAWS Adaptive applications
Overview
Centralized login is an analog of .Net Passport. There exists a unified storage of identities (here user identities) that applications refer to and rely on when it comes to registration of new users and authentication o existing.
Motivation for the centralization of a login
- a lot of users use multiple applications but have separate logins for them
- maintaining user identities at the site of each application is costly and ineffective
Note
User identity is not user model/profile, user application specific data about user is not a part of identity
User Identity fields
Incorporating group and group membership information has been postponed till further more thorough discussion.
Planned course of action
- developers should provide their user identity data for future merger
- identity data should be retrieved from Central User Identity Store and not from a local application
- conflicts in user names should be resolved in an organized fashion when needed
- interface of interaction with User Identity store to be presented later
Overview
Centralized login is an analog of .Net Passport. There exists a unified storage of identities (here user identities) that applications refer to and rely on when it comes to registration of new users and authentication o existing.
Motivation for the centralization of a login
- a lot of users use multiple applications but have separate logins for them
- maintaining user identities at the site of each application is costly and ineffective
Note
User identity is not user model/profile, user application specific data about user is not a part of identity
User Identity fields
- Mandatory fields
- Name: Last, Given
- Login
- Password
- Recommended
- gender
- Optional
- Organization/Affiliation
- City + State (Region outside U.S.)
- ZIP (Postal code)
- Country
- Comments (How did you hear about us, etc)
Incorporating group and group membership information has been postponed till further more thorough discussion.
Planned course of action
- developers should provide their user identity data for future merger
- identity data should be retrieved from Central User Identity Store and not from a local application
- conflicts in user names should be resolved in an organized fashion when needed
- interface of interaction with User Identity store to be presented later