Federated security
A Federated security system is an arrangement for managing identities and access to resources that span companies or security domains. It avoids identity duplication and security administration at multiple locations and provides an easy way of managing identities and providing them with access to information and services in a trusted manner.
In a federated system, a group of organizations shares identity attributes based on mutual trust and agreed-upon standards, facilitating authentication from other members of the federation, and granting appropriate access to online resources. Authentication is a process to verify the identity of the users and system processes. TotalAgility uses the federated security system or claim-based identity for authentication.
Claims-based identity or federated authentication is a much more flexible solution for authentication in TotalAgility Azure and on-premise. TotalAgility can leave the authentication to be done by a trusted third-party identity provider and only deal with the claims returned for the authenticated user.
Claims contain multiple statements the authenticated user or organization makes about itself or another subject. For example, a statement can be about a name, group, buying preference, ethnicity, privilege, association, or capability. Claim tokens are signed to verify they have been issued by the correct identity provider.
TotalAgility uses Web Services Federation Language (WS-Federation) and Security Assertion Markup Language (SAML) protocols that allow users that have already logged in to one site to access another site without logging in again. Single sign-on (SSO) is a subset of a federated security system in which a user's single authentication ticket or a claim token is verified across multiple IT systems or even organizations.
An identity provider provides a Security Token Service. Examples of identity providers include:
A security token service authenticates a user and returns a claims token. To better understand the concept of security token service, consider the analogy of a nightclub with a doorman. The doorman wants to prevent the entry of underage patrons. To facilitate this, he requests a patron to present a driver's license, health insurance card, or other identification (the token) that has been issued by a trusted third party (the security token service), such as the provincial or state vehicle license department, health department or insurance company. The nightclub thus alleviates the responsibility of determining the patron's age. It only trusts the issuing authority (and of course makes its judgment of the authenticity of the token presented).
By completing these two steps, the nightclub authenticates the patron to be of legal drinking age.
Similarly, the nightclub may have a membership system, and certain members may be regular or VIPs. The doorman might ask for another token, the membership card, which might make another claim; that the member is a VIP. In this case, the trusted issuing authority of the token would probably be the club itself. If the membership card claims that the patron is a VIP, then the club can react accordingly, translating the authenticated VIP membership claim to permission, such as the patron being permitted to sit in the exclusive lounge area and be served free drinks.
A federation provider provides a security token service that trusts other security token services (also known as a Resource security token service). A federation provider can perform claims transformation on the token received from the trusted security token service.
Examples of federation providers include:
The reply URL specified in the Federated Provider that is being used with TotalAgility should be as follows: https://[host]/TotalAgility/FederatedLogin.aspx. This is how the Federated Provider knows where to find TotalAgility so that it can return after authentication is completed.
In a load-balanced environment, TotalAgility cannot correctly read the passed token from AD FS consistently as the load-balanced servers have unique machine Key identifiers by default. To configure TotalAgility with AD FS in a load-balanced environment, you must generate the machine key and propagate it to all servers.
An application that relies on claims is a relying party application, also known as a "claims aware application" and "claims-based application", for example, TotalAgility. Web applications and Web services can both be relying upon parties. A relying party application consumes the tokens issued by a security token service and extracts the claims from tokens to use them for identity-related tasks.
In TotalAgility, you can provide response signature verification certificates to verify that any claims passed are from the correct provider. If validation is passed at least for one certificate, the response is considered valid. You can also define user claim rules to indicate which user groups are mapped to the TotalAgility worker group, category, and working category after they have been successfully authenticated by the provider.
Once a user is automatically added to TotalAgility after the logon to the authentication provider, any further logons will not update any settings.
See Create a resource.
You can define a set of mappings to determine how an existing user in TotalAgility is found when logon is performed after the user is successfully authenticated by the authentication provider.
How to: Configure the federated security