Re: [security-dev] IdentityManager API review

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.

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