[security-dev] IdentityManager API review
bdawidow at redhat.com
Mon Nov 12 06:16:05 EST 2012
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:
>>> void setAttribute(IdentityType identityType, String attributeName,
>>> String attributeValue);
>>> String getAttribute(IdentityType identityType, String
>>> 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
>>> 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
>> 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.
>> security-dev mailing list
>> security-dev at lists.jboss.org
> security-dev mailing list
> security-dev at lists.jboss.org
More information about the security-dev