This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, please contact Okta Support.
Hide sensitive attributes
Okta allows you to mark an attribute in the Okta user profile as sensitive, which ensures that no one in Okta can view the information stored in that attribute field. No Okta admins or end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using apps to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. will have access to any data marked sensitive.
Only Okta Super admins can mark an attribute as sensitive and use sensitive attributes in SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. assertions or mapping attributes.
To mark an attribute as sensitive, you must first map the attribute from the appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. to the Okta user profile. For details on mapping attributes to the Okta user profile, see Work with Okta user profiles and attributes.
- Allows you to hide sensitive attribute values from end users and all Okta admins.
- Only Super admins can map sensitive attributes to or from an app to the Okta user profile.
- Only Super admins can mark an Okta attribute as sensitive.
- Super admins can use sensitive attributes in SAML assertions to apps.
- Must be a Super adminThe super admin receives full access to every item in the Administrative Console and is the only role that can assign administrator roles to other user accounts. Accounts with other administrator role assignments have reduced functionalities to different permission sets. Contact Okta support to create an Okta Mastered account with Super Admin rights. to mark an Okta attribute as sensitive and to map a sensitive attribute to or from the Okta user profile. For adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. permissions, see Administrator.
To mark an existing mapped attribute as sensitive:
- While logged in as a Super admin, navigate to Directory > Profile Editor.
- Select the Okta user profile and click Profile.
- In the attribute list, locate the attribute you want to mark as sensitive and click the information icon .
- Click the Sensitive data checkbox.
Note: Only the following Okta base attributes can be marked sensitive:
- Address, address1
- Home Email, homeEmail
- City, city
- Zip Code, zipcode
- The User Permission field will always be Hide for sensitive attributes.
- Save the attribute change.
In the end user's profile, the sensitive attribute value will be displayed as asterisks.
Passing sensitive data from one application to another through Okta.
For example, if you wanted to pass along a user's employee number from a downstream app to an upstream app but do not want that information visible to Okta users or admins, you can mark that attribute as sensitive. If the employee number is stored in AD, you would map the AD attribute to the appropriate field in the Okta user profile and mark the Okta attribute as sensitive. Then map the Okta attribute to the upstream app (for example, Workday). The data will flow from AD through Okta to Workday.
Including sensitive attributes in SAML 2.0 app attribute statements.
You can also use these sensitive attributes in SAML assertions to provide extra validation when an end user is signing in to an app. To use sensitive attributes in the attribute statements, you must be logged in as a Super admin. For details, see Mapping Active Directory, LDAP, and Workday Values in a Template SAML or WS Fed Applications.
- Do not mark a sensitive attribute as required — The end user will see an error message when they edit their profile prompting them to correct "Value for required property sensitive" is missing. The Okta user profile will be expecting the attribute but the end user will not be able to see or edit the attribute. End users cannot save their profile changes until a Super admin edits the Okta user profile to mark the attribute as not required.
- The User Permission field — This field will always be treated as Hide for sensitive attributes. Changing the setting will not change the behavior of the field.
API access management — If API access management is enabled for your tenant, the following roles are able to see all attributes in the API token preview functionality in the Admin UI: Super admin, OrgThe Okta container that represents a real-world organization. admin, Read-only admin, and API AM admin.