Pass User Attributes

The Datawiza Access Proxy (DAP) gets user attributes from IdP and can pass the user attributes to the upstream application via header or cookie. You can configure these attributes on Datawiza Cloud Management Console (DCMC).

Here are the configuration options for passing user attributes:

• Profile
  Using Profile Editor, you can extend and customize app-specific profiles. This attribute can be used by Mappings, Rules or Attribute Pass.

• Mappings
  Map IdP attributes to the DAP application attributes. If you are using multiple IdPs, the similar attributes of different IdPs can be mapped to the same attributes of DAP application. If you are using a Generic OIDC, don't forget to correct the mapping sources.

• Attribute Pass
  Define what user attributes (e.g., firstName and lastName) will be sent to the proxied application via header or cookie.

Now, we will set Okta and Auth0 as IdP and show how to config to send first name (firstName of Okta and given_name of Auth0) to the proxied application. The simple architecture is like:

On DCMC, click the name of your DAP application, then select Profile.

1. By default, we will add five basic attributes, email, username, lastName, firstName and groups. You can add other custom attributes as well.
2. If you assign IdPs in IdP Configuration (We assign Okta and Auth0 as the example), the default mappings for basic attributes will be added: It is used to map user attributes from IdP to the DAP application. In the example above, firstName of Okta and given_name of Auth0 will be mapped to firstName in the DAP application.
3. After configuring in Profile and Mappings, the final step is to add attribute pass:

• Field - The attribute name of your DAP application mapped from IdP.
• Expected - The name for the header or cookie value expected by the upstream application.
• Type - It could be Header, Cookie, or JWT (If you select JWT here, attributes will be passed to upstream through HTTP header DW-TOKEN. You can see here for more details).

We just need to add one config: Field: firstName, Expected: firstname.

Then, firstName of Okta and given_name of Auth0 will be passed to upstream application in the name of firstname.

The example above discusses a typical use case involving header-based authentication. By default, attribute values will remain unchanged. However, it raises an interesting question: how should one handle situations where a single Identity Provider (IdP) is utilized for different applications, each of which requires unique attribute values?

Consider the following instance: suppose you have two services, AirFlow and SuperSet. Each has a dedicated administrator — John for AirFlow and Alex for SuperSet. Both administrators need an admin role in their respective services. If the IdP designates both users' roles as admin, it would undoubtedly cause confusion.

To resolve this issue, you could assign specific roles in the IdP such as airflow_admin for John and superset_admin for Alex. Then, using our provided expression mapping, you can map these specialized roles back to the universal admin role. This process simplifies the administration and enhances clarity and specificity in role designation. For AirFlow: For SuperSet:

And here is examples of the results of different expression maps for different user attribute vales:

Attribute Value	Expression	Result
hr, sales	map("hr", "eng");	eng
hr	map("HR","ENG")	Empty
Hr, hr	map("Hr", "Eng");map("hR", "enG");	Eng
Hr, hR	map("Hr", "eng");map("hR", "eng");	eng
hr	map("hr","eng");map("hr","sales");	eng
sales	map("hr","eng");	Empty
hr	map("hr","eng"); map("eng","sales");	sales
hr, sales	map("hr","eng"); map("sales","qa");	eng, qa

• Note:
  • Only the values in the map will be kept. Other values will be dropped.
  • This function is case-sensitive.