Levels of Assurance and Claims-based authentication
Federal Agencies must comply with OMB 04-04 publication. There is an established framework asserting different levels of assurance for digital identities, such as user accounts/passwords, Smart Cards and other types of tokens.
Claims-based authentication solutions must support the proper assertion of the level of assurance for couple different reasons:
- STS must be able to assert that issued claims-based token has certain level of assurance;
- Relaying Party might request to provide in the claims-based token the level of assurance of the authenticating identity and provide certain level of access based on that information.
Since the STS will issue claims-based tokens based on already authenticated identity, it must be able to distinguish the level of assurance of the authenticated identity and be able to include, if necessary, identity assurance level in the issued claims-based tokens.
So how STS can learn about level of assurance and still provide seamless Single Sign On?
The benefit of the Microsoft based STS is its ability to accept Windows Integrated Authentication (Kerberos tokens) and based on that token issue appropriate claims-based tokens. In architecture described in this paper the STS never authenticates the actual identity, it never asks to provide UserID/password or user certificate. If it did ask for it, then we’d not have SSO experience. So the STS cannot learn directly from the identity itself about its level of assurance, it must learn about it from the Kerberos token and keep SSO experience intact.
Fortunately, there is a solution that will satisfy this requirement.
Active Directory® Domain Services (AD DS) in the Windows Server® 2008 R2 operating system introduces new feature - authentication mechanism assurance. Authentication mechanism assurance is an added capability in Windows Server 2008 R2 AD DS that you can use when the domain functional level is set to Windows Server 2008 R2. When it is enabled, authentication mechanism assurance adds an administrator-designated global group membership to a user’s Kerberos token when the user’s credentials are authenticated during logon using a certificate-based logon method. This makes it possible for network resource administrators to control access to resources, such as files, folders, and printers, based on whether the user logs on using a certificate-based logon method, in addition to the type of certificate used. For example, when a user logs on using a smart card, the user’s access to resources on the network can be specified as different from what the access is when the user does not use a smart card (that is, when the user logs on by entering a user name and password).
Authentication mechanism assurance can be used to accommodate assurance requirements. Microsoft STS can learn about level of assurance of the authenticated identity by examining presented Kerberos ticket and build the appropriate claims-based token.