PicketLink's Identity Management (IDM) features provide a rich and extensible API for managing the identities (such as users, groups and roles) of your applications and services. It also supports a flexible system for identity partitioning, allowing it to be used as a complete security solution in simple web applications and/or as an Identity Provider (IDP) in more complex multi-domain scenarios.

The Identity Management features of PicketLink are accessed primarily via the following three interfaces:

Interaction with the backend store that provides the persistent identity state is performed by configuring one or more IdentityStores. PicketLink provides a few built-in IdentityStore implementations for storing identity state in a database, file system or LDAP directory server, and it is possible to provide your own custom implementation to support storing your application's identity data in other backends, or extend the built-in implementations to override their default behaviour.

If you'd like to get up and running with IDM quickly, the good news is that PicketLink will provide a default configuration that stores your identity data on the file system if no other configuration is available. This means that if you have the PicketLink libraries in your project, you can simply inject the PartitionManager, IdentityManager or RelationshipManager beans into your own application and start using them immediately:

@Inject PartitionManager partitionManager;

@Inject IdentityManager identityManager;

@Inject RelationshipManager relationshipManager;

Once you have injected an IdentityManager you can begin creating users, groups and roles for your application:

The Identity Model is a set of classes that define the security structure of an application. It may consist of identity objects such as users, groups and roles; relationships such as group and role memberships; and partitions such as realms or tiers. The classes found in the org.picketlink.idm.model package define the base types upon which the identity model is built upon:

A custom identity model typically consists of two types of objects - the identity objects which define the security constructs of an application, and the relationships which define how the identity objects interract with each other to establish a meaningful security policy. PicketLink treats both types of object in an abstract manner, so it is up to the developer to create meaning for these objects and their relationships within the context of their own application. This section will describe how to create new identity objects and customize their properties and attributes, while the following section will complete the picture by describing how custom relationships are created.

Let's start by looking at the source for some of the identity objects in the sample model, starting with the Agent and User objects:

public class Agent extends AbstractIdentityType implements Account {

    private String loginName;


    public Agent() { }


    public Agent(String loginName) {

        this.loginName = loginName;

    }


    @AttributeProperty

    @Unique

    public String getLoginName() {

        return loginName;

    }


    public void setLoginName(String loginName) {

        this.loginName = loginName;

    }

}

public class User extends Agent {

    private String firstName;

    private String lastName;

    private String email;


    public User() { }


    public User(String loginName) {

        super(loginName);

    }


    @AttributeProperty

    public String getFirstName() {

        return firstName;

    }


    public void setFirstName(String firstName) {

        this.firstName = firstName;

    }


    @AttributeProperty

    public String getLastName() {

        return lastName;

    }


    public void setLastName(String lastName) {

        this.lastName = lastName;

    }


    @AttributeProperty

    public String getEmail() {

        return this.email;

    }


    public void setEmail(String email) {

        this.email = email;

    }

}

The Agent class is intended to represent a third party entity that may authenticate against an application, whether human (a user) or non-human (an external or remote process). Because Agent implements the Account marker interface, it is making a declaration that this identity object is capable of authenticating. To support the typical username/password authentication method, the Agent class defines a loginName property, however since the Account interface enforces no particular method of authentication (instead of a using username for authentication your application may require a certificate or fingerprint) this property is arbitrary.

The User class represents a human user and extends Agent to add the human-specific properties firstName, lastName and email. Since human users are also capable of authenticating it will also inherit the loginName property from the Agent.

One of the strengths of PicketLink is its ability to support custom relationship types. This extensibility allows you, the developer to create specific relationship types between two or more identities to address the domain-specific requirements of your own application.

To create a custom relationship type, we start by creating a new class that implements the Relationship interface. To save time, we also extend the AbstractAttributedType abstract class which takes care of the identifier and attribute management methods for us:

  public class Authorization extends AbstractAttributedType implements Relationship {

        

  }

The next step is to define which identities participate in the relationship. Once we create our identity property methods, we also need to annotate them with the org.picketlink.idm.model.annotation.RelationshipIdentity annotation. This is done by creating a property for each identity type.

  private User user;

  private Agent application;

  

  @RelationshipIdentity

  public User getUser() {

    return user;

  }

  

  public void setUser(User user) {

    this.user = user;

  }

  

  @RelationshipIdentity

  public Agent getApplication() {

    return application;

  }

  

  public void setApplication(Agent application) {

    this.application = application;

  }

We can also define some attribute properties, using the @RelationshipAttribute annotation:

  private String accessToken;

  

  @RelationshipAttribute

  public String getAccessToken() {

    return accessToken;

  }

  

  public void setAccessToken(String accessToken) {

    this.accessToken = accessToken;

  }

PicketLink has been designed from the ground up to support a system of partitioning, allowing the identity objects it manages to be separated into logical groupings. Partitions may be used to split identities into separate realms, allowing an application to serve multiple organisations (for example in a SaaS architecture) or to support a multi-tier application allowing each tier to define its own set of identity objects (such as groups or roles). PicketLink's architecture also allows you to define your own custom partition types, allowing more complex use cases to be supported.

The PartitionManager interface provides the following methods for managing partitions:

public interface PartitionManager extends Serializable {


    <T extends Partition> T getPartition(Class<T> partitionClass, String name);


    <T extends Partition> T lookupById(final Class<T> partitionClass, String id);


    void add(Partition partition);


    void add(Partition partition, String configurationName);


    void update(Partition partition);


    void remove(Partition partition);

}