Skip to main content

Data Lineage View

Data Lineage allows you to manage and visualize data included in tokens issued by the SecureAuth platform down to a single attribute, all within a single application page.

Data Lineage Overview

Data Lineage - IDP attributes mapped to Authentication Context and to Claims

Data Lineage is a tool allowing you to manage and visualize data included in tokens issued by SecureAuth down to a single attribute, all within a single application page. You can perform the following actions via Data Lineage:

  • Map attributes from different IDPs to a common Authentication Context.

    Note

    You can also map IDP attributes to Authentication Context when configuring an IDP. Data lineage, however, allows you to map attributes from multiple IDPs in a single page.

  • Check what data is exposed to the SecureAuth-protected application down to a single claim.

  • Visualize the entire data flow - from the incoming IDP attribute to the claim issued by SecureAuth.

  • Check how data is protected with policies before being exposed to the target application. If necessary, you can conveniently access the policy configuration pages via the contextual links.

You can see the following items in the Data Lineage page:

  • The icon next to the Data Lineage title allows you to run the tour of the Data Lineage UI and open this documentation.

  • The Identities column shows IDPs connected to SecureAuth with their attributes grouped inside an IDP-dedicated list. This is, essentially, a visualization of data incoming to SecureAuth. You can drag and drop these attributes on the Authentication Context attributes to create a mapping.

    Note

    You need to select an IDP attribute in order to see its current mappings.

  • The Authentication Context column shows the SecureAuth schema, which is used as a source of data for tokens issued by SecureAuth. You need to map the IDP attributes from Data sources to corresponding SecureAuth attributes in Authentication Context so that SecureAuth can populate the Authentication Context with values based on user data sent with an authentication request. You can see how the Authentication Context attributes are populated with data from IDPs and passed on to token claims received by the client application. Use the Show all switch to see all attributes, including unmapped ones.

    Note

    Select an Authentication Context attribute in order to see its mappings.

    Note

    When you connect an IDP from a template (for example, by selecting GitHub instead of the generic OIDC connector), default mappings are created automatically. This is the most typical scenario. Typically, you only need to map attributes manually when handling custom connector implementation.

  • The Applications column shows client applications connected to SecureAuth. You can see how the claims issued in a token to a given app are populated with data from the Authentication Context. Click on a claim to see how it is mapped to the Authentication Context. If you drag an attribute from Authentication Context, a new claim is issued to this app within an access token, provided that the app requests its scope.

    Note

    Keep in mind that claims are normally grouped in scopes. This means that you cannot delete a connection between Authentication Context and an individual claim - you are prompted to remove all claims grouped within the same scope.

  • The Data governance column shows the full data flow between the IDP and the client application for a given claim, including policies. You can use the contextual links for policy configuration in order to change the current policy assignments. Going from the top to the bottom, you can see the following items:

    • IDPs feeding data to the Authentication Context attribute used by this claim.

    • Workspace policy, which refers to the Client registration policy in your workspace authorization settings. For more information, see Configuring the SecureAuth workspace.

    • Application policy, which refers to the User policy in your application configuration. For more information, see Creating and configuring applications in SecureAuth.

    • Data policy, which refers to the Consent Grant policy set on the scope to which this claim belongs. For more information, see Protecting scopes with access policies.

    • Consent type required before sending data to the target client application. For more information, see Consents.

    • Finally, the client application logo, as registered in SecureAuth.

In this section: