IdentityManager review - queries
by Shane Bryzak
I've started reviewing the IdentityManager interface to see where we can
improve the API. The first area I'd like to visit is the Query API, of
which I've come to the conclusion that we need to do some serious
redesign - the current API is non-intuitive, too verbose and not future
proof.
What I'd like to do is throw it all out and start again, replacing it
with a new cleaner API that looks something like this:
public interface IdentityManager {
// <snip other methods>
<T extends IdentityType> IdentityQuery<T> createQuery();
}
public interface IdentityQuery<T extends IdentityType> {
public enum Param {id, key, created, expired, enabled, firstName,
lastName, email, name, parent, memberOf};
public enum Operator { equals, notEquals, greaterThan, lessThan };
IdentityQuery<T> reset();
IdentityQuery<T> setParameter(Param param, Object value);
IdentityQuery<T> setParameter(Param param, Operator operator,
Object value);
IdentityQuery<T> setAttributeParameter(String attributeName, Object
value);
IdentityQuery<T> setAttributeParameter(String attributeName,
Operator operator, Object value);
IdentityQuery<T> setRange(Range range);
List<T> getResultList();
}
This unified API basically replaces the 4 separate existing interfaces
we currently have; UserQuery, RoleQuery, GroupQuery and
MembershipQuery. I've put together a few usage scenarios to show how it
might work:
1) Find users with first name 'John':
List<User> users = identityManager.<User>createQuery()
.setParameter(Param.firstName, "John")
.getResultList();
2) Find all expired users:
List<User> users = identityManager.<User>createQuery()
.setParameter(Param.expired, Operator.lessThan, new Date())
.getResultList();
3) Find all users that are a member of the "Superuser" group
List<User> users = identityManager.<User>createQuery()
.setParameter(Param.memberOf, identityManager.getGroup("Superuser"))
.getResultList();
4) Find all sub-groups of the "Employees" group:
List<Group> groups = identityManager.<Group>createQuery()
.setParameter(Param.memberOf, identityManager.getGroup("Employees"))
.getResultList();
5) Find all disabled roles:
List<Role> roles = identityManager.<Role>createQuery()
.setParameter(Param.enabled, false)
.getResultList();
6) Find all Users, Groups and Roles that have been granted the "Payroll
Officer" role in the "Human Resources" group:
List<IdentityType> identities = identityManager.<IdentityType>createQuery()
.setParameter(Param.memberOf, identityManager.getGroup("Human
Resources"))
.setParameter(Param.memberOf, identityManager.getRole("Payroll
Officer"))
.getResultList();
7) Find all Users that have an attribute named "Citizenship" with a
value of "Greenland":
List<User> users = identityManager.<User>createQuery()
.setAttributeParameter("Citizenship", "Greenland")
.getResultList();
I'm *pretty* certain that this API is at least as capable as what we
currently have, if not more so, and IMHO provides a far simpler and more
versatile design (being able to select different IdentityTypes in a
single query I think is a big plus). I'd love to hear any feedback on
whether you like it, hate it or can think of any improvements to the
design to make it better for our developers. Also, please think
especially about additional usage scenarios and whether or not there are
any particular use cases which might be problematic for this API.
Thanks!
Shane
13 years, 11 months
PicketLink Timed Release 3.0-2012Oct30
by Pedro Igor Silva
Hi All,
As the PicketLink IDM is changing a lot (for much better) we decided to release a timed version for those projects using PicketBox 5. We did that because some of the latest changes had some impact on PicketBox code and features.
For now, we changed the PicketLink IDM dependency version to 3.0-2012Oct30 (Timed Release Version).
We'll keep monitoring the IDM changes and apply them on PicketBox.
Regards.
Pedro Igor
13 years, 11 months
Merged in Social code into PL workspace
by Anil Saldhana
Shane,
recently I merged in the social login code under "social". This is
plain vanilla code for login using facebook and google. I need to move
some code for twitter login.
Next we are going to move the federation code under "federation". This
will provide the SAML object model/parsing/writing.
Since I have OAuth2 implementation, I am wondering whether I should just
merge into social or keep a separate module called "oauth". I am leaning
toward the latter.
Regards,
Anil
13 years, 11 months
Compilation issues on PicketLink repository
by Bruno Oliveira
Good morning everyone.
We on AeroGear have been using PicketBox and PicktLink for real, in nowadays have 3 real dependencies:
- picketbox-cdi which depends on picketbox-core
- picketbox-core which depends on picketlink
- picketlink
Today I'm facing with compilation issues on PicketLink repository (https://github.com/picketlink/picketlink/commits/master), I know about the fact that PicketLink is a work in progress, but I would like to ask a favour.
If the code doesn't compile and that's a working in progress could you please create a separated branch for it until the compilation issues are fixed?
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
13 years, 11 months
Added IdentityStoreInvocationContext
by Shane Bryzak
Just to add to the previous changes, I've also made a change to the
IdentityStore API so that each method includes an
IdentityStoreInvocationContext parameter. This API was first introduced
by Bolek in PicketLink 1.x [1] and offers a robust method of passing
context-specific state to individual IdentityStore invocations.
I can't think of any more elegant design that addresses this requirement
or improves on the work Bolek has already done, so beyond any minor
tweaks to the API I think we should stick with the motto "if it ain't
broke, don't fix it".
I've gone ahead and updated both (JPA and LDAP) IdentityStore
implementations to include these parameters. Along the way though, it
seems I've broken a couple of the LDAP tests; Pedro or Anil, could you
please take a look at these as my LDAP is a little rusty - I've attached
the stack trace output from the test run.
[1]
https://github.com/picketlink/picketlink-idm/tree/1.4/picketlink-idm-spi/...
13 years, 11 months
Feature set metadata for IdentityStore
by Shane Bryzak
To enable us to support partitioning within the identity management
module, I'd like to implement a feature similar to what we had in the
previous version of PicketLink IDM, FeaturesMetaData [1]. The
IdentityStore interface returns an instance of this (see [2]) which can
be used to determine the exact capabilities supported by that
IdentityStore instance. This is important for use cases such as where
users may be stored in one identity store (such as an LDAP directory),
and role and group memberships might be stored in another store (e.g. a
database).
I will probably implement this in a slightly different fashion using a
Set of enum values instead, however the functionality will by and large
remain the same. If anyone has any feedback on this proposal, please
let me know otherwise I'll proceed with the implementation in the next
day or so.
Shane
[1]
https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-spi/...
[2]
https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-spi/...
13 years, 11 months
IdentityStore changes
by Shane Bryzak
Guys,
I've made a couple of minor changes to IdentityStore to simplify the API
as follows:
1) Removed method createUser(String id)
This method was redundant, as the implementation simply delegated to the
other overloaded method of the same name:
public User createUser(String id) {
return createUser(new SimpleUser(id));
}
Also, it would (IMO) be extremely rare for a user to be created without
any of its other properties or attributes, such as first name, last
name, e-mail address, etc. We can still provide a createUser(String)
method on the IdentityManager interface for the convenience of the User
(my preference is not to have one at all), but make IdentityManager
responsible for creating the User instance.
2) Changed return type from createUser(User user) from User to void.
Returning a User from this method when it already accepts a User
parameter is also redundant. I tossed up whether we should return a
boolean instead, but decided against it because if user creation fails
for whatever reason we should really be throwing an exception instead.
I'll try to make the update to the LDAP identity store myself to reflect
these changes. Just a heads up though that there will most likely be
more changes coming as I discover further shortfalls in the API, so any
assistance with keeping the various implementations synchronized with
the API would be greatly appreciated.
Shane
13 years, 11 months
