Bugzilla – Full Text Bug Listing
| Summary: | [server] We need an internal Orion user profile | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> | ||||||||||
| Component: | Client | Assignee: | Szymon Brandys <Szymon.Brandys> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | aniefer, john.arthorne, malgorzata.tomczyk, Mike_Wilson, tomasz.zarna | ||||||||||
| Version: | 0.2 | ||||||||||||
| Target Milestone: | 0.2 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 336546, 336699, 336700 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Szymon Brandys
Malgorzata Janczarska wrote: This is how I see it: Like Jazz we should have our internal user profiles that identify users regardless the method he or she has used for authentication. This profile should contain general user information like a real-life name and may be as well used to keep rules we use for authorization. On attachment 93 [details] I've drown how I see the relationships between user accounts. I think that discussion on Enhancement 465 is leading us towards conclusion that one user may have: - 1 internal EclipseWeb account - I think this is something provided by out xml useradmin store. A user store that allows adding/removing/modifying users - Any number of OpenID accounts, but one OpenID account should be bound only to one internal user profile. OpenID account is identified by OpenID provider and OpenID user - Any number of custom user accounts, currently we have W3 support but this is only an example of a custom authorization that anyone may implement and plug into Eclipse Web And this is how I think it should work from the user perspective: 1. directly after first login by any authorization method a profile window should be presented to the user (my UI proposal is attachment 95 [details]) - in this case I would add a message somewhere on the top "Welcome to EclipseWeb, please complete user profile" 2. The profile should be pre-filled with as much data we can get from external providers - for W3 we can download user first and last name from LDAP and set intranet id as user login - I'll need to find out if we can get any personal information from OpenID provider 3. User may edit data in profile, including the internal login - we should decide if we want to force user to set password for internal login or if user leaves it empty he just won't be able to authenticate by EclipseWeb account - Or maybe it should be configurable, maybe some deployers would like to authenticate user only by other accounts? 4. User may add/remove other types of accounts ("External Accounts") section. - I think that before we add an external account we should authenticate user with it to make sure it's really his account. We can use well known OpenID popup window for it or Eclipse Web login window with user and password. 5. After user saves this profile he can use EclipseWeb and if he desires to change his profile again he should have a button next to the login name (attachment 94 [details]) How do you like my ideas? Szymon Brandys wrote: If a user is logged in using OpenID, the only thing he could, but not have to provide is the user name and the displayed name. If he didn't provide that, we would have to generate them or get from authentication providers. Anyway I would not force the user to fill anything. All other details may be updated later on the profile page. The question is, if we should let the user change the login name, if it is generated by EW. (In reply to comment #2) > Szymon Brandys wrote: > > If a user is logged in using OpenID, the only thing he could, but not have to > provide is the user name and the displayed name. If he didn't provide that, we > would have to generate them or get from authentication providers. Anyway I > would not force the user to fill anything. All other details may be updated > later on the profile page. > > The question is, if we should let the user change the login name, if it is > generated by EW. If using OpenID, I don't think we need to have a different user ID. What I suggest is that internally we have a UUID representing a unique user. That internal ID is never shown to the user, and can never be changed. If using form login, a login username/password would be associated with that UUID. If using OpenID, then an OpenID would be associated with our internal UUID. (In reply to comment #1) > Malgorzata Janczarska wrote: > - we should decide if we want to force user to set password for internal > login or if user leaves it empty he just won't be able to authenticate by > EclipseWeb account I don't understand this part. What's an "internal login"? Created attachment 187021 [details]
Small "Create User" form on Login Dialog
Before we change remove all current UI for adding users and create new one with full user profile we should support the simplest solution. Attached patch adds a small "Create user" from to the login dialog. The old "Create Users" will be removed in this task later on.
(In reply to comment #3) > If using OpenID, I don't think we need to have a different user ID. Web apps sometimes allow to create a login, log in using it and then associate the account with some Open Ids. So next time the user can choose to log in either using login/password or OpenID. Created attachment 187026 [details]
Refactoring in User Service
(In reply to comment #5) > Created attachment 187021 [details] > Small "Create User" form on Login Dialog > > Before we change remove all current UI for adding users and create new one with > full user profile we should support the simplest solution. Attached patch adds > a small "Create user" from to the login dialog. The old "Create Users" will be > removed in this task later on. I have released this patch for Malgorzata Created attachment 187033 [details]
User Service refactoring
(In reply to comment #9) > Created attachment 187033 [details] > User Service refactoring I've released this as well. Created attachment 187098 [details]
Fixed Xhr calls
My previous patch contained an error: after creating new user the system automatically logged the newly created user in, but all the on hold xhr call were not renewed. This patch fixes this problem.
I added IOrionUserProfileService and its implementation on Secure Storage. I will raise a separate bug for changes in UserServlet. It should allow to work with the profile now, not only credentials. I also raised a separate bug for using the same profile when logged using different authentication mechanisms e.g. the Orion account and OpenID (see Bug 336699) |