What is claims-based authentication? - Security Center 5.8

Security Center Administrator Guide 5.8

series
Security Center 5.8
revised_modified
2020-08-17

Claims-based authentication is the process of authenticating a user based on a set of claims about its identity contained in a trusted token. Such a token is often issued and signed by an entity that is able to authenticate the user by other means, and that is trusted by the entity doing the claims-based authentication.

What is a claim?

A claim is a statement that one subject makes about itself or another subject. The statement can be about a name, identity, key, group, privilege, or capability, for example. Claims are issued by a provider, and they are given one or more values and then packaged in security tokens that are issued by an issuer, commonly known as a security token service (STS).

What are the benefits of claims?

Claims decouple the process of authentication (verifying that an entity is what it claims to be) from the process of authorization (establishing the rights an entity has over the features and resources of a system). The benefit of this decoupling is that it allows for single sign-on (the use of a single user authentication for multiple IT systems or even organizations). Claims also add context to the user's identity, allowing you to configure more flexible access policies.

In the context of Security Center, the process of authentication is handled by a custom STS or an Active Directory Federation Services (ADFS) server, and the process of authorization is handled by Security Center itself, through partitions and privileges.

What methods of user authentication does Security Center support?

Security Center supports the following user authentication methods:
Native Security Center authentication
The user provides a username and a password to the client application to log on to Security Center.
Active Directory authentication
The user clicks Use Windows credentials and logs on using their Windows user account (requires to set up Active Directory integration).
ADFS active authentication
(WS-Trust protocol) The client application sends the username and password to a trusted identity provider (ADFS server) for authentication.
ADFS passive authentication (or web-based authentication)
(WS-Federation protocol) The client application redirects the user to a web form managed by a trusted identity provider (ADFS server). The identity provider can request any number of credentials to authenticate the user without going through the client application. Multi-Factor Authentication (MFA) can be implemented through this method.
NOTE: Users federated through ADFS are only created in Security Center on first logon. Unlike Active Directory, you do not have the option to create all imported users in Security Center when the ADFS role connects to the ADFS server.

Requirements

To use ADFS for authentication, the following conditions must be met:
  • The client workstation must be able to reach the ADFS server.
  • The HTTPS encryption certificate of the ADFS service must be trusted by the client workstation.

Performance impact

  • The scalability of the Directory is not impacted by this feature.
  • User logons using ADFS credentials are expected to take slightly longer than regular logons, because they require that the client workstations connect to one or more remote ADFS servers before connecting to the Directory.

Backward compatibility

ADFS active authentication is supported for client workstations running an older version of Security Desk or SDK, but only if the password is entered by the user.