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 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
- By default, we will add five basic attributes,
groups. You can add other custom attributes as well.
- 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,
firstNameof Okta and
given_nameof Auth0 will be mapped to
firstNamein the DAP application.
- After configuring in
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
JWT(If you select
JWThere, 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:
firstName of Okta and
given_name of Auth0 will be passed to upstream application in the name of
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:
|hr, sales||map("hr", "eng");||eng|
|Hr, hr||map("Hr", "Eng");map("hR", "enG");||Eng|
|Hr, hR||map("Hr", "eng");map("hR", "eng");||eng|
|hr, sales||map("hr","eng"); map("sales","qa");||eng, qa|
- Only the values in the map will be kept. Other values will be dropped.
- This function is case-sensitive.