[security-dev] IDM API - Final review
Anil Saldhana
Anil.Saldhana at redhat.com
Tue Nov 27 10:17:35 EST 2012
On 11/26/2012 05:16 PM, Shane Bryzak wrote:
> On 11/27/2012 07:47 AM, Anil Saldhana wrote:
>> On 11/26/2012 03:14 PM, David M. Lloyd wrote:
>>> I don't think the attribute API is really sophisticated enough for any
>>> nontrivial usage. A string key will yield inconsistent naming policies
>>> and questions of key ownership.
>>>
>>> There are two key use cases for that API that I can see:
>>>
>>> 1. User preference storage. In this case, the user would have (perhaps
>>> indirect) access to these values for the purposes of changing their
>>> preferences and other user-controlled data.
>> David, are you thinking of the Java Preferences API here?
>> http://docs.oracle.com/javase/6/docs/api/java/util/prefs/Preferences.html
>>
>> I have never personally used them. But I am wondering are you referring to
>> IDM having its own implementation of the Java Pref class? Would that be
>> better?
> I took a quick look at this, and I think we could implement this as an
> add-on feature (i.e. not part of the IdentityManager itself, but still
> based on our Identity model) if David agrees that it will meet the
> requirements. Although I think that the Attributes API as it stands
> should be able to support the user preferences use case (we just never
> give the user direct control over the attribute keys, they would instead
> go through a facade).
IMO PL can provide an implementation of the Preferences API. Then we
bridge it to our attributes api in the PrefencesFactory implementation
(http://docs.oracle.com/javase/6/docs/api/java/util/prefs/PreferencesFactory.html).
Typically it is used in desktop applications to store user preferences.
By default, the preferences are stored by the JDK in the Windows
Registry (Windows), Library/Preferences (Mac) and user home directory
(Unix). See below.
========
http://stackoverflow.com/questions/1320709/preference-api-storage
For Windows systemRoot and userRoot are stored in
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs and
HKEY_CURRENT_USER\Software\JavaSoft\Prefs respectively.
For Unix systemRoot and userRoot are stored in "user.home" +
".java/.userPrefs" and "/etc/.java" respectively.
Note that for Unix the locations can be changed by specifying
"java.util.prefs.userRoot" and "java.util.prefs.systemRoot" properties
===============
The benefit of Preferences API is that it is a Java API. Applications
already making use of it can continue to use it by changing the PL
preferences implementation.
The default implementation of the Java Preferences is a single node
implementation. It fails in a clustered environment. This is one of
the reasons why users like to change the preferences implementation to
something that is not default. Ideally the storage should be DB or LDAP,
implies IDM.
>>> 2. Per-application, per-user information storage. In this case the
>>> application might be storing non-role access or authorization
>>> information (e.g. how many of resource XYZ am I alloted?), or non-user
>>> controlled configuration.
> This one is a little trickier. The model currently only supports
> storing User attributes within the realm, and they are
> Tier(Application)-independent. I can't currently think of a way to
> easily support per-tier attributes that isn't going to be extremely
> messy, although leave it with me for a while and I'll see if I can come
> up with something.
>
>>> On 11/20/2012 04:41 PM, Shane Bryzak wrote:
>>>> I've updated the IdentityManager API based on the latest design, could
>>>> everyone please take a couple of minutes to review and let me know if
>>>> you spot any issues. We'll probably do a time-boxed release (Anil,
>>>> could you please confirm?) shortly so that projects consuming PLIDM can
>>>> start building against the API.
>>>>
>>>> Thanks,
>>>> Shane
>>>>
>>>>
>>>> public interface IdentityManager {
>>>> void bootstrap(IdentityConfiguration configuration,
>>>> IdentityStoreInvocationContextFactory contextFactory);
>>>>
>>>> void setIdentityStoreFactory(IdentityStoreFactory factory);
>>>>
>>>> // User
>>>>
>>>> void createUser(User user);
>>>>
>>>> void removeUser(User user);
>>>>
>>>> void updateUser(User user);
>>>>
>>>> User getUser(String name);
>>>>
>>>> // Group
>>>>
>>>> void createGroup(Group group);
>>>>
>>>> void removeGroup(Group group);
>>>>
>>>> Group getGroup(String groupId);
>>>>
>>>> Group getGroup(String groupName, Group parent);
>>>>
>>>> boolean isMember(IdentityType identityType, Group group);
>>>>
>>>> void addToGroup(IdentityType identityType, Group group);
>>>>
>>>> void removeFromGroup(IdentityType identityType, Group group);
>>>>
>>>> // Roles
>>>>
>>>> void createRole(Role role);
>>>>
>>>> void removeRole(Role role);
>>>>
>>>> Role getRole(String name);
>>>>
>>>> boolean hasRole(IdentityType identityType, Role role, Group group);
>>>>
>>>> void grantRole(IdentityType identityType, Role role, Group group);
>>>>
>>>> void revokeRole(IdentityType identityType, Role role, Group group);
>>>>
>>>> boolean hasApplicationRole(IdentityType identityType, Role role);
>>>>
>>>> void grantApplicationRole(IdentityType identityType, Role role);
>>>>
>>>> void revokeApplicationRole(IdentityType identityType, Role role);
>>>>
>>>> // Query API
>>>>
>>>> <T extends IdentityType> IdentityQuery<T> createQuery();
>>>>
>>>> // Credential management
>>>>
>>>> boolean validateCredential(User user, Credential credential);
>>>>
>>>> void updateCredential(User user, Credential credential);
>>>>
>>>> // User / Role / Group enablement / expiry
>>>>
>>>> void setEnabled(IdentityType identityType, boolean enabled);
>>>>
>>>> void setExpirationDate(IdentityType identityType, Date expirationDate);
>>>>
>>>> IdentityType lookupIdentityByKey(String key);
>>>>
>>>> // Attributes
>>>>
>>>> void setAttribute(IdentityType identityType, Attribute<? extends
>>>> Serializable> attribute);
>>>>
>>>> <T extends Serializable> Attribute<T> getAttribute(IdentityType
>>>> identityType, String attributeName);
>>>>
>>>> void removeAttribute(IdentityType identityType, String attributeName);
>>>>
>>>> // Realm
>>>>
>>>> void createRealm(Realm realm);
>>>>
>>>> void removeRealm(Realm realm);
>>>>
>>>> Realm getRealm(String name);
>>>>
>>>> // Tier
>>>>
>>>> void createTier(Tier tier);
>>>>
>>>> void removeTier(Tier tier);
>>>>
>>>> Tier getTier(String id);
>>>>
>>>> // Context
>>>>
>>>> IdentityManager forRealm(Realm realm);
>>>>
>>>> IdentityManager forTier(Tier tier);
>>>> }
>>>>
More information about the security-dev
mailing list