Introduction

The primary purpose of identity management systems is to manage data belonging to users; it is common practice in such systems to define as well entities called roles that helps in defining and enforcing security policies. In addition to this, Syncope explicitly represents the fact that users can be assigned to roles by mean of memberships.

In summary, Syncope manages data about three kind of entities:

1. User
2. Role
3. Membership

When saying "data", Syncope refers to a collection of so-called attributes.

This means that Syncope will manage User attributes, Role attributes and Membership attributes.

Attribute

An attribute is a (key,values) pair where

• key is a string label (i.e. Surname)

• values is a (possibly singleton) collection of data (i.e. [Doe] but also [john.doe@syncope.apache.org, jdoe@gmail.com])

The type of values that can be assigned to each attribute is defined via schemas.

Syncope will manage plain attributes, derived attributes and virtual attributes for users, roles and memberships.

Plain attributes

In this case attribute values are persisted into the Syncope internal storage.
Plain attribute values are:

• updated via synchronization from external resources
• available for propagation towards external resources

Read-only

Read-only attribute value(s) cannot be changed via standard operations (e.g. REST, synchronization from external resources, ...). Such attributes are reserved for internal usage, so their value(s) can be changed only in the underlying DBMS or from inside the workflow.

Derived attributes

Sometimes it is handful to obtain values as arbitrary combination of other attributes' values: for example, with 'Firstname' and 'Surname' plain attributes, it is natural to think that 'Fullname' could be somehow defined as the concatenation of Firstname's and Surname's values, separated by a blank space.

You can define a derived attribute via a JEXL expression combining values of some plain attributes.

Derived attribute values are:

• indirectly updated via synchronization from external resources (when component plain attributes' values are updated via synchronization)
• available for propagation towards external resources

Virtual attributes

With virtual attributes, values are not kept into the Syncope internal storage but somehow linked from an external resource.

For performance optimization, virtual attributes are managed by an internal cache to limit access to external resources.

The typical usage of virtual attributes is when an attribute can change on an external resource without notice and there is need of having access to the most updated value without relying upon synchronization.

Virtual attribute values are:

• unaffected by synchronization
• available for propagation towards external resources

Read-only

When attribute value(s) from an external resource are needed only to be read within Syncope, and can only be changed from the own resource, virtual read-only attributes are fit for the job.

Schema

An attribute schema describes the values that attributes with that schema will held:

• type (String, Enum, Boolean, Long, Double, Date)
• whether values must respect UNIQUE constraint or not
• whether values must be singleton or not
• whether providing a value is mandatory or not
• whether input is accepted or not (read-only)
• whether values must be validated by some provided validator (like as EMailAddressValidator)
• how non-string values must be converted into / parsed from strings (conversion pattern)

This means that Syncope will manage schemas, derived schemas and virtual schemas for users, roles and memberships.

Schema Mapping

If Syncope was only able to define schemas and manage attributes for its internal storage, there would have been little to profit from by deploying an IdM solution.

One of most important features is about to link such attributes to external resources (LDAP server, Database, ...) so that propagation and synchronization can take place effectively.