[security-dev] IDM security model - Human vs Non human users

Jason Porter lightguard.jp at gmail.com
Thu Oct 18 11:31:39 EDT 2012

Attributes are fine as long as there's an easy way to access them. We something better then below IMO:

Boolean isHuman = (Boolean) idm.getAttribute("human", user);

If (isHuman)

If its an attribute we have in every model, something we're specifying could we not add simple convenience methods?

Sent from my iPhone

On Oct 18, 2012, at 7:20, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> Such as an attribute on the User called "human" set to true or false to 
> indicate humans or machines?
> On 10/18/2012 08:14 AM, Pedro Igor Silva wrote:
>> Hi Shane,
>>     I think we can avoid changing the IDM Model by using attributes. That way we can handle that internally by setting some specific attribute(s).
>>     Attributes are a nice way to extend the IDM model (Users, Roles and Groups), they can act as a metadata and help to extend information for specific cases.
>> Regards.
>> Pedro Igor
>> ----- Original Message -----
>> From: "Shane Bryzak" <sbryzak at redhat.com>
>> To: security-dev at lists.jboss.org
>> Sent: Thursday, October 18, 2012 8:52:46 AM
>> Subject: [security-dev] IDM security model - Human vs Non human users
>> Bolek and I were discussing $SUBJECT quite some time ago, and we came to
>> the conclusion that it would be nice to be able to differentiate between
>> users that are human, and users that are not. I hope that everyone can
>> appreciate why this might be important for today's interconnected web.
>> Anyway, I've been contemplating an elegant way to implement this, and
>> I'd like to run the following idea past you guys.
>> Currently, the User interface extends IdentityType, like so:
>>      public interface User extends IdentityType
>> This interface declares mostly human-specific methods (besides getId()
>> and possibly get/setEmail()):
>>      String getId();
>>      String getFirstName();
>>      void setFirstName(String firstName);
>>      String getLastName();
>>      void setLastName(String lastName);
>>      String getFullName();
>>      String getEmail();
>>      void setEmail(String email);
>> What I would like to do, is introduce another interface in between User
>> and IdentityType, called Agent:
>>      public interface Agent extends IdentityType {
>>          String getId();
>>          String getEmail();
>>          void setEmail(String email);
>>      }
>> The User interface would then extend this and provide the human-specific
>> methods:
>>      public interface User extends Agent {
>>          String getFirstName();
>>          void setFirstName(String firstName);
>>          String getLastName();
>>          void setLastName(String lastName);
>>          String getFullName();
>>      }
>> This change would require some modifications to the IdentityManager
>> interface.  We currently have the following user-related methods:
>>      User createUser(String name);
>>      User createUser(User user);
>>      void removeUser(User user);
>>      void removeUser(String name);
>>      User getUser(String name);
>>      Collection<User> getAllUsers();
>>      UserQuery createUserQuery();
>> (as a side note, we will probably remove some of these methods for
>> simplicity sake)
>> I see two choices here; 1) we can either leave these methods as-is and
>> add another set of methods for Agents (createAgent(), removeAgent(),
>> etc), or 2) we can update the methods to work with Agents instead of
>> Users (as a User is an Agent anyway).  I am kind of leaning towards
>> option 1) because it keeps it simple and intuitive for developers, but I
>> also like option 2) because it reduces the overall number of methods.
>> That basically sums up the idea.  This will give us support for
>> non-human connections to an application, and provides some
>> future-proofing should any similar requirements come along later. I'd be
>> interested in hearing any feedback on this, for the overall idea in
>> general and specifically for the IdentityManager changes.
>> Shane
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev

More information about the security-dev mailing list