//
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements.  See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership.  The ASF licenses this file
// to you under the Apache License, Version 2.0 (the
// "License"); you may not use this file except in compliance
// with the License.  You may obtain a copy of the License at
//
//   http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing,
// software distributed under the License is distributed on an
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
// KIND, either express or implied.  See the License for the
// specific language governing permissions and limitations
// under the License.
//
=== Users, Groups and Any Objects

Users, Groups and Any Objects are definitely the key entities to manage: as explained <<introduction,above>>
in fact, the whole identity management concept is literally about managing identity data.

The following identities are supported:

* *Users* represent the virtual identities build up of account information fragmented across the associated external 
resources
* *Groups* have the dual purpose of representing entities on external resources supporting this concept (say LDAP or
Active Directory) and putting together Users or Any Objects for implementing group-based provisioning, e.g. to
dynamically associate Users or Any Objects to external resources
* *Any Objects* actually cover very different entities that can be modeled: printers, services, sensors, ...

For each of the identities above, Apache Syncope is capable of maintaining:

. `name` (`username`, for Users) - string value uniquely identifying a specific user, group or any object instance;
. `password` (Users only) - hashed or encrypted value, depending on the selected `password.cipher.algorithm` - see
<<configuration-parameters, below>> for details - which can be used for authentication;
. set of attributes, with each attribute being a `(key,values)` pair where

 ** `key` is a string label (e.g. `surname`);
 ** `values` is a (possibly singleton) collection of data (e.g. `[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 the <<schema,schema>> matching the `key`
value (e.g. _plain_ and _derived_);
. associations with <<external-resources,external resources>>, for <<provisioning,provisioning>>.

[IMPORTANT]
.Which schemas can be populated for a given user / group / any object?
====
Each user / group / any object will be able to hold values for all schemas:

. defined in the <<AnyTypeClass,Any Type classes>> associated to their <<AnyType, Any Type>>;
. defined in the <<AnyTypeClass,Any Type classes>> configured as *_auxiliary_* for the specific instance.
====

Moreover, Users and Any Objects can be part of Groups, or associated to other any objects.

[[memberships-relationships]]
[NOTE]
.Memberships and Relationships
====
When an user or an any object is assigned to a group, a *_membership_* is defined; the (static) members of a group
benefit from <<type-extensions,type extensions>>.

When an user or an any object is associated to another any object, a *_relationship_* is defined, of one of available
<<relationshiptype,relationship types>>.
====

[TIP]
.Static and Dynamic Memberships
====
Users and Any Objects are _statically_ assigned to Groups when memberships are explicitly set.

With group definition, however, a condition can be expressed so that all matching Users and Any Objects are
_dynamic_ members of the group. +
Dynamic memberships have some limitations: for example, <<type-extensions,type extensions>> do not apply;
group-based provisioning is still effective.
====

[[security-questions]]
[NOTE]
.Security Questions
====
The <<password-reset,password reset>> process can be strengthened by requesting users to provide their configured
answer to a given security question, chosen among the ones defined.
====
