Using Data Lineage
Learn about the data integration possibilities brought to you by Authorization Control Plane's Data Lineage.
To use Data Lineage for demonstration purposes, you only need access to an ACP 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 ACP.
About Data Lineage
Data Lineage is a tool allowing you to manage and visualize data included in tokens issued by ACP 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.
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 ACP-protected application down to a single claim.
Visualize the entire data flow - from the incoming IDP attribute to the claim issued by ACP.
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 Data sources column shows IDPs connected to ACP with their attributes grouped inside an IDP-dedicated list. This is, essentially, a visualization of data incoming to ACP. You can drag and drop these attributes on the Authentication Context attributes to create a mapping, as shown in the video below.
You need to select an IDP attribute in order to see its current mappings.
The Authentication Context column shows the ACP schema, which is used as a source of data for tokens issued by ACP. You need to map the IDP attributes from Data sources to corresponding ACP attributes in Authentication Context so that ACP 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.
Select an Authentication Context attribute in order to see its mappings.
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 ACP. 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.
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 ACP workspace.
Application policy, which refers to the User policy in your application configuration. For more information, see Creating and configuring applications in ACP.
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 ACP OAuth consents.
Finally, the client application logo, as registered in ACP.
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
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. To make sure the claim is requested by the app,
we are assigning a scope to it before logging in.
As a result, the following happens:
Customclaim is created in the authorization server and assigned to the app in an access token. The
Customscope (matching the claim name) is assigned to the claim automatically.
We are assigning an additional scope to the claim so that the claim is requested by the target app.
Upon a successful authentication via an IDP, the application receives the requested scopes, including the
Customclaim in the access token issued by ACP.