[security-dev] IdentityManager API review

[Boleslaw Dawidowicz]

On Nov 12, 2012, at 4:01 AM, Shane Bryzak <sbryzak at redhat.com> wrote:

> On 11/08/2012 11:32 PM, Bolesław Dawidowicz wrote:
>> 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.
>> 
>> 
>> 
> 
> Ok, so let's just keep it simple for now and support String valued 
> attributes. If we ever decide to support more complex types, backwards 
> compatibility shouldn't be an issue as String is Serializable anyway.
> 
>>>     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?
> 
> Yes, the key is a unique identifier and can be used to identify a 
> specific User, Group or Role. At present the format I was going with 
> looks similar to a URL, i.e. USER://sbryzak, GROUP://employees/managers, 
> ROLE://admin etc.

You'll need a double check if there is no issue to pass those as url params or in REST context. 

> 
>> 
>> B.
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev