Overview of Claims-based Authentication
Claims-based authentication (CBA) is built on Windows Identity Foundation (WIF), a framework for building Windows-based, claims-aware applications and security token services (STSs) that is standards-based and interoperable. Interoperability is provided through reliance on industry standard protocols such as WS-Federation, WS-Trust, and Security Assertion Markup Language 1.1 (SAML).
In claims-based authentication, an identity provider, or security token service, responds to authentication requests and issues SAML security tokens that include any number of claims about a user, such as a user name and groups the user belongs to. A relying party application receives the SAML token and uses the claims inside to decide whether to grant the user access to the requested resource. Claims-based authentication can be used to authenticate your organization's internal users, external users, and users from partner organizations.
K2 relies on the configuration of a K2 user manager to provide authentication and user and group resolution for identity stores such as Active Directory, SQL, LDAP or a custom store. For more information see the topic: Introduction to User Managers.
K2 provides the ability for incoming claims-based authentication through configuration of mappings between claims-based identity providers and K2 user managers. For more information, see the Claims References topic.
For information on how to configure K2 Services to support Claims Authentication, see KB001426
Do not register multiple security labels against the SSPI (Windows Security Provider). Doing so will result in users being resolved incorrectly.
Claims-based Authentication needs to be configured and working on the K2 blackpearl server before starting the claims configuration for K2 smartforms sites.
Known Supported Scenarios
The following Claims-Based Authentication (CBA) scenarios are known to be supported. Note that this list is not exhaustive since there may be other CBA scenarios that will also work.
- Claims-based Authentication for federated claims identities such as ADFS, Azure AD, etc.
- The use of a Windows Identity Foundation (WIF 3.5 only) utility (FedUtil) to configure a SmartForms runtime site to support federated claims-based users on existing environments. New installs do not need any changes to the SmartForms web.config with regards to claims config as it is pre-configured for claims against the K2 blackpearl Windows STS and Forms STS.
- When the runtime site is used in the K2 smartforms Viewer web part on a SharePoint site, flow-through of the claims users’ identities is managed for providers in SharePoint that are ‘trusted’. However, there is a one-to-one mapping between the identity provider and the SmartForms runtime site and you cannot have multiple identities at the same time with the web part.
- Windows-based users (wrapped in claims or not) with a standard Windows authentication runtime site.
- Multiple identity providers on the same runtime site (see Introduction to Multi-Auth).
- Multiple ‘trusted’ providers configured or using a Windows or Forms-based user login where the runtime site is used in the K2 smartforms Viewer Web Part on a SharePoint site (see Introduction to Multi-Auth).
- Forms-based users wrapped in claims is supported if configured against FormsSTS, and the appropriate security provider is configured.
When Windows STS authentication OR Forms STS authentication is enabled, it is important to frequently save work that has been done in the K2 Designer as work might be lost when the same session is left open for 8 hours or longer.