How-tos

5 mins read

Using Data Lineage

Learn about the data integration possibilities brought to you by Authorization Control Plane's Data Lineage.

Prerequisites

To use Data Lineage for demonstration purposes, you only need access to an Cloudentity tenant with a workspace. Your authorization server should already contain pre-configured IDPs, authentication context, and initial data mappings, which should be enough to get an idea of the data flow in Cloudentity.

About Data Lineage

Data Lineage is a tool allowing you to manage and visualize data included in tokens issued by Cloudentity 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 Cloudentity-protected application down to a single claim.

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

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

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 Cloudentity with their attributes grouped inside an IDP-dedicated list. This is, essentially, a visualization of data incoming to Cloudentity. You can drag and drop these attributes on the Authentication Context attributes to create a mapping, as shown in the video below.

    Note

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

  • The Authentication Context column shows the Cloudentity schema, which is used as a source of data for tokens issued by Cloudentity. You need to map the IDP attributes from Data sources to corresponding Cloudentity attributes in Authentication Context so that Cloudentity 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 Cloudentity. 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 Cloudentity workspace.

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

    • 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 Cloudentity OAuth consents.

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

Map Attributes to Authentication Context

In the video below, we are adding the Login attribute, which is a part of user data incoming from GitHub, to the Nickname attribute which is defined in the Authentication Context schema. As a result, the nickname claim in the generated ID token has the user’s GitHub login as a value.

Map your attributes and claims in a similar fashion to make sure that you’re sending the correct data to correct applications.

Create New Claims from Authentication Context

In the video below, we are mapping the name IDP paramter to a Custom authentication context attribute. Then, we are creating a new Custom claim by dragging the attribute from the authentication context area to the application area.

As a result, the following happens:

  • New Custom claim is created in the authorization server and assigned to be requested by the app. The Custom scope (matching the claim name) is assigned to the claim automatically.

  • Upon a successful authentication via an IDP, the application receives the requested scopes, including the Custom claim in the tokens issued by Cloudentity.

Updated: Jul 11, 2022