Federated security

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

  • On-Premise: Windows Server Active Directory with AD FS 2.0 (supports SAML 2.0 and other tokens formats)

  • Public Cloud: Windows Azure Active Directory

  • One Login

A security token service authenticates a user and returns claims token. To better understand the concept of security token service, consider the analogy of a night club with a doorman. The doorman wants to prevent under-age patrons from entry. 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 is thus alleviated of the responsibility of determining the patron's age. It only has to trust the issuing authority (and of course make its own 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 VIP. 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 makes the claim 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 provider include:

  • On-Premise: Windows Server Active Directory with AD FS 2.0

  • Public Cloud: Windows Azure Active Directory, Windows Azure Active Directory Access Control.

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 machineKey identifiers by default. To configure TotalAgility with AD FS in a load balanced environment, you must generate the machinekey and propagate it to all servers.

An application that relies on claims is a relying party application, also known as claims aware application and claims-based application, for example, TotalAgility. Web applications and Web services can both be relying 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 as 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.

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

See Configure the federated security.