[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Re: IdAS user accounts management proposals
|
Jim,
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)
Each open Context instance can have more than one DigitalSubject instance,
so we need to perform authentication for Context, not for Subject. In other
words, when we say "DigitalSubject which stores authentication data should
have predefined attribute types like password, cardKeyHash, etc", it means
that we need to declare some DigitalSubject type with these attribute types
in schema. But:
a) when we open the context an first time, it is assumed there already
should exist such instance of DigitalSubject (IContext.open() returns its
ID);
b) when the user create, for example, two such subjects, each subject has
"password" ("cardKeyHash") attribute and we can not know which subject we
need to use for authentication. You can say that we need to operate with the
subject which has not empty "password" attribute but I am not sure it is
good way.
c) we need to be able to manage user accounts(to control user
name/cardKeyHash originality, to know how many users we have etc).
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:
Now to add self-signed credentials (cardKeyHash) we need to open the
context, get "default" subject and change some its attribute. I think we
need to have more convenient/standardized way to manage authentication
materials.
Thanks,
Sergey Lyakhov
----- Original Message -----
From: "Jim Sermersheim" <jimse@xxxxxxxxxx>
To: <higgins-dev@xxxxxxxxxxx>
Sent: Wednesday, December 05, 2007 12:11 AM
Subject: [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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
