KB003017

This article in the series briefly describes the relationships between User Managers, Identity Providers, Claims, and Realms, and how these terms apply to K2.

Articles in this Series

• Authentication and Authorization in K2
• Claims-based Authentication in K2
• Outbound Authorization an OAuth in K2
• About K2Trust
• Troubleshooting Claims-based Authentication Issues
• Understanding User Managers, Identity Providers, Claims, and Realms (this article)

User Managers

"User Manager" (also sometimes referred to as user label or simply label) is a K2-specific term and refers to an instance of a configured Identity Provider. For example, the AD User Manager is the User Manager that resolves user identities against Active Directory. The AAD User Manager is the User Manager that resolves identities against Azure Active Directory.

A K2 environment could have multiple User Managers configured, and each will have a unique label. For example, the default label for the AD User Manager is "K2", while the default label for the AAD User Manager is "K2AAD". The label is included in the Fully-Qualified Name (FQN) in a user identity in K2, for example, K2:DenallixBob, where K2 is the label of the user manager associated with Active Directory, Denallix is the domain where the user account is located, and Bob is the user name. This combination of [label]:[domain][username] represents a unique user in K2.

Different labels represent either different Identity Providers (IdPs) such as Active Directory (AD) or a user and role provider, such as AD FS. Note that if the same user is present in two different labels, for example, AAD:bob@denallix.onmicrosoft.com and K2:DenallixBob, these are considered two separate and distinct user accounts even though it may be the same person signing in with different identities.

When installing K2 Five in an Active Directory environment, the K2 label is configured automatically. If AD is not detected, you must configure the SQL User Manager which uses the K2SQL label. K2 Cloud is configured with the K2AAD label representing Azure Active Directory.

You must have at least one user manager configured to allow people to log in to K2. K2 Cloud only supports one user manager, but you can configure multiple user managers in K2 Five. For more information see Introduction to User Managers.

Identity Providers

Identity Providers are the repositories where user accounts are stored and are used by K2 to authenticate, resolve or look up information about users. Identity Providers are associated with a User Manager in K2. For example, the AD User Manager, with the label K2, is associated with your Active Directory domain. Azure Active Directory (label: K2AAD) and the K2 SQL User Manager (label: K2SQL) are other examples of Identity Providers.

The Identity Provider stores the username, password, and other user properties, and K2 refers to this information when it needs to authenticate, resolve or read information about a user. K2 does store usernames and passwords (encrypted, of course) for user accounts stored in the K2 SQL User Manager.

Claims

Claims in K2 terms actually refer to Claims tokens, which are a piece of Claims-based Authentication.

Claims-based authentication is user authentication that uses claims-based identity technologies and infrastructure. Applications such as K2 that support claims-based authentication obtain a security token from a trusted issuer (such as AAD) on behalf of the user, rather than credentials, and use the information within the claims to determine access to resources. The token contains information about the user, such as the groups that the user belongs to. K2 uses this information to determine what resources the user is allowed to access.

A Claim/Claim Token is essentially a unique and secure token that is issued by a Secure Token Service (STS), and this Claim Token represents a user authenticated by the Identity Provider associated with the STS. To put it differently, think of the claims token as a trustworthy 'certificate' that a user gets once they have authenticated successfully, along with information about the user that K2 uses to determine whether that user has access to the resource that they want to connect to. The user then 'presents' this 'certificate' to K2 when they connect to K2. In the background, K2 has a Claims Mapping that tells K2 which STS (and ultimately, which Identity Provider) the user was authenticated by. The Claims Mapping allows K2 to locate and trust the STS and map the user information in the claim to a label. If necessary, for example when the user's token has expired, K2 can then redirect the user to log into the Identity Provider again to obtain a new token. 

In technical terms, K2 serves as a relying party and is not a provider of claims.  For more about Claims-Based authentication in K2, please see the article Claims-Based Authentication in K2. In order for K2 to understand identities passed as claims tokens, you must set up claims mappings and associate them with a user manager. Typically this is configured for you, but you can do this manually as well. For more information about configuring claims, see Claims.

Realms

Realms are part of Claims-Based Authentication. They are resources linked to a claims issuer, and typically represent a site, such as https://k2.denallix.com/designer. The realms associated with the issuer give users access to those resources. You can have multiple realms per issuer, and at least one audience per realm. For more information see Realms and Audiences.