Skip to main content

At high-level how Federated Security is used to authenticate a KTA logon

Article # 3036436 - Page views: 10


You would like to understand how Federated Security works. The goal of this KB is to describe at high-level how Federated Security using Microsoft Active Directory as the Identity Provider(IDP) is used to authenticate a KTA logon.


What is Federated Security?

With Federated Security, the responsibility for authenticating a user is moved from the application (KTA) to the IdP. This has the advantage that all applications can use the same IDP. You do not have to manage the same identity at different locations. Federated security uses claim based identity for identifying users. When a user is authenticated by the IDP, the IDP provides the application with a claim that describes the authenticated user.

A claim contains one or more statements about an authenticated user. These claims descriptions are specified as Uri’s. E.g.

<Attribute Name="">
<AttributeValue>John Doe</AttributeValue>

To ensure that a returned claim token from the IDP can be a trusted public key infrastructure (PKI) is used. The IDP signs the claim token with his private key and the application (KTA) verifies the signature with the public key of the IDP. In the application (KTA) it also specifies the URL of the issuer.

Every identity provider publishes a federated metadata XML that describes the endpoints (URLs), the claim descriptions and contains the public key for checking the signature.




How does the authentication operate?

1. A user tries to access KTA (https://kta/TotalAgility/designer/)

2. KTA finds the IDP to authenticate the user. If there is only one, it’s picked as the IDP. If there are multiple IDP, the user is provided with a choice what IDP to use.

3. KTA creates an authentication request and redirects the user’s browser to the IDP.

Example Request:

<samlp:AuthnRequest ID="_0a422c2f-264b-4c5a-8c1e-f31a0b2418f4" Version="2.0" IssueInstant="2020-07-27T14:13:19Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://kta/TotalAgility/FederatedLo...m%2flogon.html" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://kta/TotalAgility/</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" />
  <samlp:RequestedAuthnContext Comparison="exact">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>

4. IDP authenticates the user and generates a claim token for the user.

5. IDP redirects the user back to KTA with a response that contains the claim token.

6. KTA verifies the claim token by validating the signature with the configured certificate thumbprint. It also checks whether the response came from the configured issuer URL.

7. KTA verifies the claim token and uses user claim mapping to log the user in. If the user doesn’t exist yet, a new user is created using any configured user claim rules. If the user already exists, the user is simply logged in.


Example Response:

<samlp:Response ID="_44a93eac-2397-425f-b710-b40a1aee2230" Version="2.0" IssueInstant="2020-07-27T14:13:19.253Z" Destination="https://kta/TotalAgility/FederatedLo...m%2flogon.html" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_0a422c2f-264b-4c5a-8c1e-f31a0b2418f4" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adhost/adfs/services/trust</Issuer>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
  <Assertion ID="_0b1f59ab-0215-41bc-934d-4d098b77092a" IssueInstant="2020-07-27T14:13:19.253Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <ds:Signature xmlns:ds="">
      <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="" />
        <ds:SignatureMethod Algorithm="" />
        <ds:Reference URI="#_0b1f59ab-0215-41bc-934d-4d098b77092a">
            <ds:Transform Algorithm="" />
            <ds:Transform Algorithm="" />
          <ds:DigestMethod Algorithm="" />
      <KeyInfo xmlns="">
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_0a422c2f-264b-4c5a-8c1e-f31a0b2418f4" NotOnOrAfter="2020-07-27T14:18:19.253Z" Recipient="https://kta/TotalAgility/FederatedLo...m%2flogon.html" />
    <Conditions NotBefore="2020-07-27T14:13:19.251Z" NotOnOrAfter="2020-07-27T15:13:19.251Z">
      <Attribute Name="">
      <Attribute Name="">
        <AttributeValue>John Doe</AttributeValue>
      <Attribute Name="">
    <AuthnStatement AuthnInstant="2020-07-27T13:55:49.764Z">

Let’s discuss the above 6 & 7 steps in more detail:

  • The user is redirected to KTA with the above Response that contains the claim token.
  • KTA first checks the signature. The thumbprint of the signature must be configured in KTA. If the thumbprint matches with the certificate used for signing the claim token, the response is verified.
  • KTA secondly checks if the configured issuer URL matches with the issuer URL stated in the response.
  • KTA retrieves the “Username”, “Name” and “Email Address” using User Claim mapping. Whatever is configured for “Match to” under User claim mappings in KTA is used to check if a user already exists or not. To retrieve each value an Uri is specified under user claim mapping.
  • In AttributeStatement in the response, you will see the attributes (Claim descriptions) of the authenticated user. For example, the username the Uri would be:
Additional Configurations

If the user does not exist, KTA creates the user using User claim rules. The user will be created with the Category, Working Category and Working group defined in User Claim rules under Default User claim. By default, every new user is added to the everyone group.

You can enable Custom User Rules under User Claim Rules. This enables you to specify a rule for matching a claim type/description with a value. For example, if you have a claim description that contains the department someone belongs to, you can enter the Uri of that claim description and its value the department name. So you could have everyone from group “Sales” be created with the custom rules you defined. The advantage of custom user rules is that it enables you to add users to specific groups. 

Level of Complexity 



Applies to  

Product Version Build Environment Hardware
KTA 7.4 or above