1:40 a.m.
Hi all,
Shane, Pedro and I have been discussing the following use case and
agree on method name change. Shane suggested the list due to it being an
API change.
The developer can ask the Identity Manager to create an instance of
User/Role/Group (IdentityType). This use case is pretty clear.
Now if the developer wants to create his own instances of U/R/G as:
User user = new SimpleUser("userA");
Now he needs to persist this to the store.
The current API call would be:
User storeUser = identityManager.createUser(user)
We feel this is not as intuitive as:
User storeUser = identityManager.persist(user)
Objections to this API change?
Regards,
Anil
2:24 a.m.
Just to add to this, the idea is to essentially mimic the JPA API, which
provides persist(), merge() and remove() methods. What we are proposing
is a slight variation of this, as follows:
public interface IdentityManager {
// snip other methods
/**
* Persists the specified IdentityType
*/
void persist(IdentityType identityType);
/**
* Updates the persisted state of the specified IdentityType, with
the exception of the id and name for Groups, and name for Roles
*/
void update(IdentityType identityType);
/**
* Removes the specified IdentityType
*/
void remove(IdentityType identityType);
}
Just a reminder, that IdentityType is the super-type for User, Group and
Role so these methods can be used for any of these. This would simplify
the IdentityManager API considerably (replacing an existing 7 methods
with just 3) while providing more functionality (currently the API
doesn't allow Roles or Groups to be updated).
On 11/29/2012 10:40 AM, Anil Saldhana wrote:
Hi all,
Shane, Pedro and I have been discussing the following use case and
agree on method name change. Shane suggested the list due to it being an
API change.
The developer can ask the Identity Manager to create an instance of
User/Role/Group (IdentityType). This use case is pretty clear.
Now if the developer wants to create his own instances of U/R/G as:
User user = new SimpleUser("userA");
Now he needs to persist this to the store.
The current API call would be:
User storeUser = identityManager.createUser(user)
We feel this is not as intuitive as:
User storeUser = identityManager.persist(user)
Objections to this API change?
Regards,
Anil
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
3:16 p.m.
I prefer add() to persist(), IMO it's more obvious.
On 29 Nov 2012, at 01:24, Shane Bryzak wrote:
Just to add to this, the idea is to essentially mimic the JPA API,
which
provides persist(), merge() and remove() methods. What we are proposing
is a slight variation of this, as follows:
public interface IdentityManager {
// snip other methods
/**
* Persists the specified IdentityType
*/
void persist(IdentityType identityType);
/**
* Updates the persisted state of the specified IdentityType, with
the exception of the id and name for Groups, and name for Roles
*/
void update(IdentityType identityType);
/**
* Removes the specified IdentityType
*/
void remove(IdentityType identityType);
}
Just a reminder, that IdentityType is the super-type for User, Group and
Role so these methods can be used for any of these. This would simplify
the IdentityManager API considerably (replacing an existing 7 methods
with just 3) while providing more functionality (currently the API
doesn't allow Roles or Groups to be updated).
On 11/29/2012 10:40 AM, Anil Saldhana wrote:
> Hi all,
> Shane, Pedro and I have been discussing the following use case and
> agree on method name change. Shane suggested the list due to it being an
> API change.
>
> The developer can ask the Identity Manager to create an instance of
> User/Role/Group (IdentityType). This use case is pretty clear.
>
> Now if the developer wants to create his own instances of U/R/G as:
>
> User user = new SimpleUser("userA");
>
> Now he needs to persist this to the store.
>
> The current API call would be:
>
> User storeUser = identityManager.createUser(user)
>
> We feel this is not as intuitive as:
>
> User storeUser = identityManager.persist(user)
>
> Objections to this API change?
>
> Regards,
> Anil
> _______________________________________________
> 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
4:22 p.m.
persist() has the added meaning of update()
On 2012-11-29, at 9:16 AM, Pete Muir <pmuir(a)redhat.com> wrote:
I prefer add() to persist(), IMO it's more obvious.
On 29 Nov 2012, at 01:24, Shane Bryzak wrote:
> Just to add to this, the idea is to essentially mimic the JPA API, which
> provides persist(), merge() and remove() methods. What we are proposing
> is a slight variation of this, as follows:
>
> public interface IdentityManager {
>
> // snip other methods
>
> /**
> * Persists the specified IdentityType
> */
> void persist(IdentityType identityType);
>
> /**
> * Updates the persisted state of the specified IdentityType, with
> the exception of the id and name for Groups, and name for Roles
> */
> void update(IdentityType identityType);
>
> /**
> * Removes the specified IdentityType
> */
> void remove(IdentityType identityType);
> }
>
> Just a reminder, that IdentityType is the super-type for User, Group and
> Role so these methods can be used for any of these. This would simplify
> the IdentityManager API considerably (replacing an existing 7 methods
> with just 3) while providing more functionality (currently the API
> doesn't allow Roles or Groups to be updated).
>
> On 11/29/2012 10:40 AM, Anil Saldhana wrote:
>> Hi all,
>> Shane, Pedro and I have been discussing the following use case and
>> agree on method name change. Shane suggested the list due to it being an
>> API change.
>>
>> The developer can ask the Identity Manager to create an instance of
>> User/Role/Group (IdentityType). This use case is pretty clear.
>>
>> Now if the developer wants to create his own instances of U/R/G as:
>>
>> User user = new SimpleUser("userA");
>>
>> Now he needs to persist this to the store.
>>
>> The current API call would be:
>>
>> User storeUser = identityManager.createUser(user)
>>
>> We feel this is not as intuitive as:
>>
>> User storeUser = identityManager.persist(user)
>>
>> Objections to this API change?
>>
>> Regards,
>> Anil
>> _______________________________________________
>> 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
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
5:02 p.m.
Tough issue. :) We are getting into subjective world. The question is
what would be intuitive to a developer who uses IDM
and probably JPA.
On 11/29/2012 09:22 AM, Marius Bogoevici wrote:
persist() has the added meaning of update()
On 2012-11-29, at 9:16 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> I prefer add() to persist(), IMO it's more obvious.
>
> On 29 Nov 2012, at 01:24, Shane Bryzak wrote:
>
>> Just to add to this, the idea is to essentially mimic the JPA API, which
>> provides persist(), merge() and remove() methods. What we are proposing
>> is a slight variation of this, as follows:
>>
>> public interface IdentityManager {
>>
>> // snip other methods
>>
>> /**
>> * Persists the specified IdentityType
>> */
>> void persist(IdentityType identityType);
>>
>> /**
>> * Updates the persisted state of the specified IdentityType, with
>> the exception of the id and name for Groups, and name for Roles
>> */
>> void update(IdentityType identityType);
>>
>> /**
>> * Removes the specified IdentityType
>> */
>> void remove(IdentityType identityType);
>> }
>>
>> Just a reminder, that IdentityType is the super-type for User, Group and
>> Role so these methods can be used for any of these. This would simplify
>> the IdentityManager API considerably (replacing an existing 7 methods
>> with just 3) while providing more functionality (currently the API
>> doesn't allow Roles or Groups to be updated).
>>
>> On 11/29/2012 10:40 AM, Anil Saldhana wrote:
>>> Hi all,
>>> Shane, Pedro and I have been discussing the following use case and
>>> agree on method name change. Shane suggested the list due to it being an
>>> API change.
>>>
>>> The developer can ask the Identity Manager to create an instance of
>>> User/Role/Group (IdentityType). This use case is pretty clear.
>>>
>>> Now if the developer wants to create his own instances of U/R/G as:
>>>
>>> User user = new SimpleUser("userA");
>>>
>>> Now he needs to persist this to the store.
>>>
>>> The current API call would be:
>>>
>>> User storeUser = identityManager.createUser(user)
>>>
>>> We feel this is not as intuitive as:
>>>
>>> User storeUser = identityManager.persist(user)
>>>
>>> Objections to this API change?
>>>
>>> Regards,
>>> Anil
3:15 a.m.
I've updated the IdentityManager API so that we now support the
following User/Group/Role related methods:
// General
void add(IdentityType identityType);
void update(IdentityType identityType);
void remove(IdentityType identityType);
// User
User getUser(String name);
// Group
Group getGroup(String groupId);
Group getGroup(String groupName, Group parent);
boolean isMember(IdentityType identityType, Group group);
void addToGroup(IdentityType identityType, Group group);
void removeFromGroup(IdentityType identityType, Group group);
// Roles
Role getRole(String name);
boolean hasGroupRole(IdentityType identityType, Role role, Group
group);
void grantGroupRole(IdentityType identityType, Role role, Group group);
void revokeGroupRole(IdentityType identityType, Role role, Group
group);
boolean hasRole(IdentityType identityType, Role role);
void grantRole(IdentityType identityType, Role role);
void revokeRole(IdentityType identityType, Role role);
This change has meant a net simplification of the API, with the three
new methods (add, update and remove) replacing the seven methods we
previously had, while providing additional features (in the form of
added support for updating Groups and Roles).
Thanks for the feedback guys!
Shane
On 11/30/2012 12:16 AM, Pete Muir wrote:
I prefer add() to persist(), IMO it's more obvious.
On 29 Nov 2012, at 01:24, Shane Bryzak wrote:
> Just to add to this, the idea is to essentially mimic the JPA API, which
> provides persist(), merge() and remove() methods. What we are proposing
> is a slight variation of this, as follows:
>
> public interface IdentityManager {
>
> // snip other methods
>
> /**
> * Persists the specified IdentityType
> */
> void persist(IdentityType identityType);
>
> /**
> * Updates the persisted state of the specified IdentityType, with
> the exception of the id and name for Groups, and name for Roles
> */
> void update(IdentityType identityType);
>
> /**
> * Removes the specified IdentityType
> */
> void remove(IdentityType identityType);
> }
>
> Just a reminder, that IdentityType is the super-type for User, Group and
> Role so these methods can be used for any of these. This would simplify
> the IdentityManager API considerably (replacing an existing 7 methods
> with just 3) while providing more functionality (currently the API
> doesn't allow Roles or Groups to be updated).
>
> On 11/29/2012 10:40 AM, Anil Saldhana wrote:
>> Hi all,
>> Shane, Pedro and I have been discussing the following use case and
>> agree on method name change. Shane suggested the list due to it being an
>> API change.
>>
>> The developer can ask the Identity Manager to create an instance of
>> User/Role/Group (IdentityType). This use case is pretty clear.
>>
>> Now if the developer wants to create his own instances of U/R/G as:
>>
>> User user = new SimpleUser("userA");
>>
>> Now he needs to persist this to the store.
>>
>> The current API call would be:
>>
>> User storeUser = identityManager.createUser(user)
>>
>> We feel this is not as intuitive as:
>>
>> User storeUser = identityManager.persist(user)
>>
>> Objections to this API change?
>>
>> Regards,
>> Anil
>> _______________________________________________
>> 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
6:36 p.m.
+1
Sent from my iPhone
On Nov 28, 2012, at 18:40, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
Hi all,
Shane, Pedro and I have been discussing the following use case and
agree on method name change. Shane suggested the list due to it being an
API change.
The developer can ask the Identity Manager to create an instance of
User/Role/Group (IdentityType). This use case is pretty clear.
Now if the developer wants to create his own instances of U/R/G as:
User user = new SimpleUser("userA");
Now he needs to persist this to the store.
The current API call would be:
User storeUser = identityManager.createUser(user)
We feel this is not as intuitive as:
User storeUser = identityManager.persist(user)
Objections to this API change?
Regards,
Anil
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
4185
days inactive
4187
days old
6 comments
5 participants
participants (5)
-
Anil Saldhana -
Jason Porter -
Marius Bogoevici -
Pete Muir -
Shane Bryzak