If this topic has to do with the management of subject's credentials, then one thing we need to do before opening this up again is review the last wave of debate that revolved around it. Here are the messages that got us where we are:
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02740.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02742.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02743.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02761.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02762.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02763.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02764.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02765.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02781.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02775.html <-- Here's where we began talking about a generic way to update credentials
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02869.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02870.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02871.html <-- Here, we begin to make a case for treating credentials like other attributes
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02872.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02873.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02878.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02880.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02881.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02882.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02883.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02901.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02914.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02929.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02931.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02995.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03008.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03151.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03161.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03163.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03165.html
http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03167.html
Also see this defect:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=193223
and this wiki:
http://wiki.eclipse.org/IdAS_Change_Password
Hopefully what we did was right :)
Jim
>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 12/04/07 11:50 AM >>> Jim,
It seems current implementation of authentication in IdAS (as JNDI CP as Jena CP) using AuthNSelfIssuedMaterials credantials has some weakness. When user gets a managed card with self-issued token credential type, we open IdAS context by the user's username/password credential, and store the PPID value of self-issued card as "cardKeyHash" attribute value of DigitalSubject (where profile data is stored). So, we are storing "PPID" credential data as user data. Then, when we perform PPID-based authentication, we open IdAS context using some credentials (not related to the owner of required profile), and select DigitalSubject (profile) by "cardKeyHash" attribute. Really it does not look like the right implementation of PPID-based authentication. I suppose we need to add to IdAS interfaces the ability to manage IdAS user accounts and support of multi-credential authentication.
Maybe there is some sence to make the following changes:
1. Add a new interface IUserAccount with methods: a) getCredentials() - return all credentials of the user which can be used by this user for authentication in the Context; b) getCredentialByType(credentialType); c) addCredential() - add a new credential (like username/password credential); c) removeCredential();
2. Add to IContext the following methods: a) getSupportedCredentialTypes();
b) buildCredential(credentialType); c) createUserAccount(); d) removeUserAccount(); e) getUserAccounts(); f) getUserAccount(credential);
3. Change IContext.open(Object credentials) to return an instance of IUserAccount instead of ID of "default" DigitalSubject.
4. Also we propose to add role-based authorization mechanism in such a way: a) extend IUserAccount with methods setRole() - assign the Role to the User getRoles() - get all the Roles which user has been assigned b) extend IContext with methods createUserRole() deleteUserRole() getUserRoles() getUserAccountsByRole() c) extend IDigitalSubject with methods setPermission(permissions, roles); clearPermission(permissions); or IContext with same methods setPermissions(subjectId, permissions, roles); clearPermissions(subjectId, permissions, roles); permissions - read/modify/delete etc.
Thanks, Sergey Lyakhov
|