SAML2 Data Collection

News Knowledge Base
1

Data Collection for SAML2 Issues.

Issue Description: This article is meant to address how to gather diagnostic information related to configuration SAML 2.

Background: SAML2 was developed as a way of allowing an Organization to authenticate to a service, using their internal authentication infrastructure, without having to give the service access to their internal infrastructure.

For example, if OrgA wants to access a resource hosted by OrgB and they want to use integrated Windows authentication, they would have to have a trust relationship with OrgB. Instead they can use SAML2, which allows users from OrgA to be authenticated using integrated windows authentication via the SAML2 provider, without having to give OrgB direct access.

For the most part SAML2 works by the SAML2 provider (Okta, Windows Federated, Pingdom, etc) providing a document that attests to the persons identity. This document is transferred via the browser and it is cryptographically signed. The signature is similar to how public certs work. If we trust the certificate that was used to sign the document, we have a good guarantee it came from the SAML2 provider. (This is why our SAML2 configuration requires importing a certificate from the SAML2 provider).

The following is a list of key concepts. It can also be helpful to understand the terminology involved:

  • SP: Service Provider (SP) is the application or resource that the user is trying to access. It relies on the SAML assertion to determine whether the user should be granted access. This is Orchestrator/Identity in the UiPath Eco System.
  • Assertion: A SAML assertion is an XML document containing information about the user, their authentication status, and attributes. It is typically signed by the IdP to ensure its integrity.
  • IdP: Identity Provider (IdP) is responsible for authenticating users and issuing SAML assertions. This is the SAML2 provider (Okta, Pingdom, etc)
  • Metadata: Both the IdP and SP can exchange metadata that describes their capabilities, endpoints, and public keys. Not all SPs or Providers support this. Orchestrator can pull in the metadata of an SP for easier configuration.
  • SAML Protocol: SAML 2.0 defines several profiles for different use cases, such as Web Browser SSO, Single Logout, and Enhanced Client or Proxy (ECP) profiles. Each profile specifies how SAML assertions and other elements are exchanged between the IdP and SP.
At a high level, SAML 2.0 operates as follows:
  • User Requests Access: This is what is generated by Orchestrator/Identity when trying to access a resource.
  • SP Sends Authentication Request: The SP generates an authentication request and sends it to an Identity Provider (IdP). The IdP is responsible for authenticating the user.
  • User Authentication: The IdP challenges the user for credentials (E.g., username & password) or may use other authentication methods like multi-factor authentication.
  • IdP Issues SAML Assertion: Upon successful authentication, the IdP creates a SAML assertion. This assertion contains information about the user and their authentication status. It is digitally signed by the IdP to ensure its authenticity.
  • SAML Response to SP: The IdP sends the SAML assertion back to the SP in a SAML response. This is done via the browser.
  • SP Validates SAML Assertion: The SP validates the digital signature of the SAML assertion to ensure it comes from a trusted IdP. It may also check the expiration, issuer, and other attributes of the assertion.
  • User Access Granted: If the SAML assertion is valid, the SP grants the user access to the requested resource or application without requiring them to log in again. This is the essence of Single Sign-On.

For a more detailed overview on the HTTP calls and flow of requests, see: SP redirect request; IdP POST response .

Diagnosing/Log Gathering

  1. Gather HAR trace to capture network - Har Trace
    1. Its best to clear the cache before doing this.
    2. The HAR trace will provide a lot of information. Specifically:
      1. At which stage is the login failing
      2. Which component is causing the failure
      3. What the SAML2 request and response look like.
  2. Gather screenshots of the SAML configuration on Identity Provider and Service Provider
    1. Screen shot of the Service Provider (Orchestrator SAML configuration on the Host and/or Tenants)
      1. Example : SAML Config on Orchestrator Host LevelSAML_SPSetup.PNG
    2. Screen shot of the Identity Provider (ex: pingone, OKTA SAML Configuration )
      1. Example : OKTA IP ConfigurationOKTA_IPSetup.PNG
  3. Gather event viewer logs from Orchestrator server to get a stack trace of error and get associated date/time of when login time occurred. See: Event Viewer Logs
  4. Gather DB info from the following tables (Query can be ran as one command):
    1. The query will show users, but this is often helpful when diagnosing login issues.
    2. The results can be exported as a CSV.
    3. The DirectoryConnections/ExternalIdentityProviders might contain sensitive information. For example, an Azure AD connection might contain a secret key. Those can be removed. However, we would want to see things like servernames, etc. These are typically not sensitive and for SAML2 can be important for identifying misconfigurations.
    4. Gathering:
      1. In SQL Server Management Studio , go to Tools -> Options -> Query results > SQL Server > Results to Text
      2. Right click and save results as a csv or rpt file type
select * From [identity].ASPNETUSERS
select * From [identity].ASPNETUSERLOGINS
select * From [identity].DynamicUserGroups
select * From [identity].Groups
select * From [identity].ExternalIdentityProviders
select * From [identity].DirectoryConnections
select * From dbo.UserPartitions
select * From dbo.users