[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