[security-dev] IdentityManager API review

[Bolesław Dawidowicz]

On 11/07/2012 07:08 PM, Jason Porter wrote:
>
>     Attributes
>     -------------
>
>           void setAttribute(IdentityType identityType, String attributeName,
>     String attributeValue);
>
>           String getAttribute(IdentityType identityType, String
>     attributeName);
>
>     My thoughts:
>
>     1. This area poses a slight dilemma.  Currently the API only supports
>     simple String-based attribute values, however I'm pretty sure that
>     people are going to want to store all sorts of things, ranging from
>     boolean and Date values through to large byte arrays that store a User's
>     photograph or other data.  If everyone is in agreement that we need to
>     support more than just String values, then the first thing we probably
>     need to do is modify these methods to work with a Serializable instead.
>
>     2. If we all agree on point 1), the next thing we need to decide is
>     whether we want the capability to make some attribute values "lazy
>     loaded".  If we want to do a quick lookup of a User object for the
>     express purpose of assigning a Role or Group membership (or any other
>     type of simple operation) then we probably don't want the performance
>     hit of having to load bulky attribute data.
>
>     3. With the above two points in mind, I'm going to hold off on surmising
>     any further on attributes until some of you guys weigh in with your
>     opinions.  I do have some rough ideas, however I'll wait until we have a
>     consensus of exactly what we want to achieve here before we proceed
>     further.
>
>
> Serializable works for me. Do we do have a generic Attribute<? extends
> Serializable> or just forgo the generics?

Serializable could be fine. To be honest I'm fairly biased in this 
topic. Mainly becuase for IDM 1.x I lost quite significant amount of 
time to implement and properly test binary attributes support for like 7 
different databases. It was never really used. I would start small in 
this area. It is always possible to extend this part of the api later 
however we may find out that there is no need for this.

We should think what are our usecases for attributes. Maybe Bill should 
jump in and express his usecases and ideas. Most security tokens can be 
serialized into string I guess.

I also agree that we should spend some time to check compatibility with 
JSR351 API here. It will be so flexible that we rather won't be able to 
implement it fully however it would be good to reduce limitations for 
JSR351IdentityStore.

Another obvious usecase is storing avatar or other binary content. My 
take is that application should rather implement separate binary store 
and just keep basic reference as user attribute. I would simply veto any 
binary attribute support idea until we have clear agreement that it is 
really necessary.

Are we addressing any attribute metadata so far? This is probably more 
identity store concern however part of attributes may be marked 
readonly. Also in LDAP scenario multi value support is attribute 
specific and this info may be worth exposing in the API directly.

Another one that is quite huge is to support unique attributes. Common 
requirement is to have unique email attribute value. It is also common 
to search user by unique attribute - either email or token. This needs 
to be easy and efficient on the implementation side.



>
>     Utility methods
>     --------------------
>
>           IdentityType lookupIdentityByKey(String key);
>
>     My thoughts:
>
>     1. This method is required by other features, such as the Permissions
>     API.  I'm fine with what we have here.

Side question - how do you want to express difference between User, 
Group and Role here? Are we going to have some clear key format specified?

B.