register log on
Knowledge base
 

Implementing User Profile Management Solutions With Arnica UnifiedLogon

KB Artcile # 2808
With the growing adoption of intranets, extranets and data-driven public web sites, identity management becomes one of vital systems in the IT infrastructure. An important characteristic of any web-based data-driven system is its inherent capability to connect web applications and components developed with different languages, by different teams, running on different platforms, through loosely-coupled HTTP-based communication and language neutral XML/JSON data exchange. This promotes a fast and continuous system evolution, but also complicates project architecture development, making it nearly impossible to predict future user profile structure or anything else related to user activity in newer web applications, which may need to be integrated with the system in the future. It also creates a requirement for identity management systems to provide flexible, continuously updatable, and scalable user profile structures of virtually unlimited complexity.

User profile services make up one of the core features of an identity management system. User profile services are usually responsible for the following:
  • Persistent storage of user data
  • Real-time data delivery
  • User profile data management (user properties update; profile structure update)
  • Auditing and reporting
This article describes how user profiles are maintained by Arnica UnifiedLogon, as well as architectural user profile features and options provided by UnifiedLogon that create flexible and scalable identity management solutions. Arnica UnifiedLogon has many other features, which are often used together with profile management - such as authentication, authorization, single sign-on, configuration management, etc.; however, the focus of this article is user profile architecture. 

User profiles in UnifiedLogon are provisioned by the following data structure types (subsystems):
  1. User standard fields (properties)
  2. User global custom fields
  3. Application user custom fields
  4. User-specific data stores
  5. User configuration directory
Each user profile subsystem has its pros and cons and a specific target use scenario, but combined together they provide a flexible solution for maintaining, managing and delivering user profiles of virtually unlimited complexity and scalability for applications supporting any number of users, from a few dozen to millions.

Each user profile subsystem is reviewed below. 

User standard fields

This is a core data structure of a user profile. User standard fields include general user properties such as user name, first name, last name, email address, street address, phone number, etc. User standard fields are available immediately as soon as a user account is created. All standard fields are stored as columns in a single table.

Advantages: 

- no setup is required
- best performance via both web service APIs and database APIs 

Disadvantages:

- standard field set limited to general properties (approx. 30)

Typical use scenario:

- provide basic information about a user account




Global custom fields

Global custom fields are used to extend the set of standard fields. They are created in a separate database table, related with the standard fields table with a mandatory 1-to-1 relation. Administrators define global custom fields to extend the default set of standard fields. Same as standard fields, global custom fields are available to any user account immediately after setup. Global custom fields may be retrieved or updated using the same APIs which work with standard fields, and within the same pool of properties as the standard fields. 

Advantages:

- used in the same pool of properties as standard fields
- always available for all user accounts immediately after setup

Disadvantages:

- combined width of all global custom fields cannot exceed approx. 8000 characters
- global custom fields cannot re-use names of standard fields

Typical use scenario:

- extension of the standard field list with system-wide meaning, applicable to most user accounts, used extensively by multiple applications integrated with the identity management system 





Application user custom fields

UnifiedLogon allows to register an unlimited number of applications. An application in UnifiedLogon is an entity (similar to a project) which encapsulates various components of the functioning system, for example: resources, data sources, configuration entries, lists, and others. Application may also contain a set of user properties, which have relevance only to this particular application. Such user properties are called application user custom fields. As soon as the first application user custom field is created in the context of a particular application, a table is created in the UnifiedLogon database to maintain records containing these fields. This table has 1-to-1 non mandatory relation with the main user account, i.e. any user account may have one record in such table, or no records. As a rule of thumb, if user activity is associated with a particular application, then this user would have a data record in the application's user custom field table. Although each table has a limit for the total width of all fields of approx. 8000 characters, there may be many applications registered with UnifiedLogon, which helps to virtually infinitely expand user profile. 

Advantages:

- as an unlimited number of applications may be defined within UnifiedLogon, unlimited number of application user custom fields (distributed among applications) may be defined to support various specialized profile data
- may be set up for a subset of users who use a particular application
- may re-use standard field names or global custom field names or names of application user custom fields of other applications, without causing data conflict
 
Disadvantages:

- requires one-time initiation before application user custom fields of a particular application may be used for a given user account

Typical use scenario:

- extension of the standard field list, which is specific only to certain applications and/or is applicable to a smaller subset of users




User-specific data stores

UnifiedLogon implements data stores as tables managed in a private cloud.  UnifiedLogon provides functionality for administrators to create and manage tables in either its own database or in a separate database, which may optionally run on a different server. UnifiedLogon APIs (web service REST APIs, as well as database APIs) provide access to these data structures. Administrators have complete freedom in creating the data store structure. If a data store has reference to user system identifier (this identifier is created by administrator as one of data items in the data store), then such data store may be used to further extend user profile. Because data store structure is not restricted by any other system rules, there might be multiple records in this table corresponding to the same user, effectively implementing user profile data structure which requires 1-to-many relations with user account.

Advantages:

- allows multiple records per user per data store
- may re-use standard field names or global custom field names or names of application user custom fields of any application, without causing data conflict
- may be deployed in different databases, including on different servers
- may be independent from any application managed by UnfiiedLogon
- may be set up in relations with other entities: resources, companies, products, user groups, etc.

Disadvantages:

- requires one-time initiation (record creation) before data store fields may be used for a given user account

Typical use scenario:

- group of properties which requires multiple records per user 
- may be applicable to most user accounts or only to a small subset of user accounts
- group of properties, which are related to other entities, such as user groups, companies, products, etc., in association with a particular user account
- group of properties, which have unusually high data space or data access read/write load requirements, with the possibility to be hosted outside of the main UnifiedLogon database and/or on a different server



User configuration directory

User profile subsystems described above share one common feature: a particular user profile structure implemented with one of these methods is exactly the same for all user accounts managed by Arnica UnifiedLogon. The user profile configuration directory allows creating different profile data structures for each user, and makes it possible for a user to have different user profile data structures for different applications. The structure of configuration directory is hierarchical and consists of key name/key value pairs. 

Each key may have a value and unlimited number of subkeys, each subkey may have a value and its own subkeys, and so on. The depth of the hierarchy is unlimited in theory, but an absolute key name reference (key\child_key\grand_child_key\etc\etc\...) cannot exceed 254 characters, which is usually a reasonable range for most use scenarios. 

Administrators do not have to setup configuration directory key structure before it is used from within application code: keys are created (if access control allows it) on the fly during first time use via UnifiedLogon API,  providing configuration directory read and update functionality.

Advantages:

- hierarchical properties structure 
- different users may have different set of configuration directory-based properties
- configuration directory structure may be setup and maintained dynamically from within application code
- unlimited number of properties (keys) per user per application
- may re-use standard field names or global custom field names or names of application user custom fields, without causing data conflict

Disadvantages:

- data type is limited to character or text (up to 2 GB per value)
- good real-time performance, although may be slower in comparison with other user profile subsystems described in this article

Typical use scenario:

- any application-specific use with dynamically changed metadata (set of properties)
- profile data structures, which are not uniform across user base, or applicable only to specific users
- user profile properties, which require hierachical structure
- adhoc set of user profile properties