Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Re: IdAS user accounts management proposals

I'm confused.  Let me try to repeat what you've said and maybe you can fill in the gaps.

<possible general problem>
There is something wrong with the way we manage credentials, or with the way we use credentials to authenticate, or both (I'm not sure which is causing a problem).

<possible management problem>
When an IdAS consumer (let's use the example of an IdP) wishes to update a digital subject's credentials, and those credentials are obtained from an RST credential in the form of a self-issued token credential, the IdP will:
1) authenticate as a least-privileged user 
2) create an AuthNSelfIssuedMaterials, passing the ppid, publicKeyMod, and publicKeyExp
3) get the managed attribute from AuthNSelfIssuedMaterials.getManagedAttr()
4) update the digital subject with that managed attribute
(If there is a problem here, please explain.  Note that a userPassword and cardKeyHash are both elements on a digital subject, both could be called user data, both should have access controls applied to them)

<possible authentication problem>
When an IdAS consumer (using the example of an IdP again) wishes to authenticate a digital subject's credentials, and those credentials are obtained from an RST credential in the form of a self-issued token credential, the IdP will:
1) create an AuthNSelfIssuedMaterials, passing the ppid, publicKeyMod, and publicKeyExp
2) authenticate using the AuthNSelfIssuedMaterials created in step 1
(If this is a problem, please explain.  Note that in this case, the IdP does not open the context using some credentials not related to the owner of required profile)

You mentioned the need to support multi-credential authentication.  We currently allow this.  Let's change the authentication example above to use name/pw credentials:

When an IdAS consumer (using the example of an IdP again) wishes to authenticate a digital subject's credentials, and those credentials are obtained from an RST credential in the form of a username/password credential, the IdP will:
1) create an AuthNNamePasswordMaterials, passing the username and password
2) authenticate using the AuthNNamePasswordMaterials created in step 1

Note that the steps are exactly the same, the only thing that changes is that the IdP constructs an appropriate AuthN*Materials based on the credential type of the RST.  This allows a digital subject to be authenticated to by a number of different credentials.  

Similarly, one can manage a digital subject's username/password credentials with the same 4 steps shown in the management example above (using AuthNNamePasswordMaterials instead of AuthNSelfIssuedMaterials)

We do not yet have the ability for the context or a digital subject to report *which* types of authentication materials it supports in a direct way.  But then, we try to do most of our capabilities discovery via the model interfaces.  One should be able to look at the model, and if the model allows the attribute type returned by some AuthN*Materials.getManagedAttrURI(), to be placed on a particular digital subject, then one should be able to assume it's supported (at least from a management perspective).  

I may be way off track.  Maybe you are talking about the JNDI CP implementation, and you see a problem with the way it currently authenticates using the cardKeyHash.

In any case, I thought it would be good to make sure we were talking about the same problem(s) before proceeding.

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




Back to the top