The following sites now support Multi-Auth.
- smartforms Runtime
- smartforms Designer
- Identity
- View Flow
To enable Multi-Auth, some changes were made to how these sites work as well as how the K2 server handles authentication.
Claims Authentication
All authentication between SmartForms sites and the product is done using Claims Authentication. You can read more about claims authentication here. The basic concept is that when a user authenticates against a particular provider, that provider can issue a set of standardized claims which tells others systems who the user is and what system authenticated them. Claims configured to provide more information about a person can also be issued, but for our purposes only the Identity Provider, and Security Label claims are used.
Not all Identity Providers issue claims based security tokens today. Most notably is Active Directory which issues Windows Authentication tokens. To solve this problem K2 has provided a Security Token Service (STS) that converts Windows tokens into claims, known as the Windows STS. Similarly, since Forms Authentication also does not issue claims a Forms STS has also been provided. Systems like Active Directory Federation Services (AD FS) and Azure Active Directory (AAD) issue claims through their own STSs.
Once a claims based security token comes into the Server from SmartForms, the Server checks a list of known Claim Issuers to see if there is a match. If there is no match an exception is raised. If there is a match in the Issuer list, the security token is “cracked” so that the claims can be read. The product checks a list of claims that have been registered with the Issuer to determine who the user is. Once the identity of the user has been found the products security label that is mapped to the Issuer is added to the identity and the user is authenticated to the system.
Realms
Claims Authentication takes care of authenticating the user once the user has a security token issued from an STS. Getting the user to the right STS is all about Realms. A Realm is an identifier for a site. The system uses a URI based identifier which is the URL of the site. Other systems might use other formats such as URN.
Each SmartForms site is configured to map to a Realm. The list of Realms to choose from is configured in the product. When the SmartForms site loads it checks with the Server to understand what Issuer configurations are mapped to the Realm of the SmartForms site. If there is more than one Issuer mapped to the Realm, then the SmartForms site is in Multi-Auth mode and will present a page to the user for them to select which Issuer to use to log in. However, if there is already a security token cached in the user’s browser, the security token is sent through so that the user can be authenticated automatically without having to select an Issuer. Also, if there is only one Issuer configured for the Realm, then no login method selection is necessary and the user will be directed to the log in screen.

When the user selects an Issuer, or there is only one Issuer for the Realm, the URI that is stored with the Issuer configuration is used to route the user to the appropriate STS for log in. In the case of Windows STS, which uses Windows Authentication, the log in happens without any user interaction. In the case of other STSs like AAD, AD FS and Forms STS a login screen will be presented. The user enters valid credentials and a Security Token is attached to the redirect back to SmartForms and Claims Authentication takes over.
Below is a diagram that explains the relationship between Realms, Issuers, and Security Labels.

For authentication to work seamlessly, the Identity web application must have the same claims configuration as your Runtime SmartForms realm.