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 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:
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 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.