> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/administration/attributes/attributes-from-sso.md).

# Attributes from SSO

How attribute values arrive through the SAML assertion, and how to create, verify, and keep them current with the refresh interval.

Attribute values can arrive in Userlane through single sign-on (SSO). When someone signs in, the identity provider[^1] sends a Security Assertion Markup Language (SAML) assertion[^2] that carries attribute claims alongside the authentication itself. Whatever the identity team has mapped in the assertion comes through automatically.

This article covers creating and verifying attributes on the SSO path, and setting the refresh interval that keeps values current.

{% hint style="warning" %}
**Before you start.** SSO must already be configured and working. The identity team must have mapped the desired claims in the identity provider's SAML assertion. You need a portal administrator role to create attributes and change the refresh interval.
{% endhint %}

## How attributes arrive through SSO

SSO passes attribute values as claims inside the SAML assertion. Each claim is a key-value pair: the key is the attribute name (for example, `department` or `costCenter`), and the value is whatever the identity provider holds for that person.

Only the fields the identity team chose to include in the assertion come through. That is often fewer than the directory actually holds, because SAML mappings are configured explicitly rather than mirroring the full record. If an attribute you need is missing, the identity team adds it to the assertion mapping on their side, not in Userlane.

Values land on each user's profile the moment they sign in. From that point on, they are available for building audiences and for analytics. Users who have not signed in yet have no SSO-sourced attributes, because the assertion only fires during authentication.

## Create attributes in the portal or let SSO create them

There are two ways attributes come into existence when SSO is the source.

The first is to create them manually in the portal before SSO delivers any values. This is the recommended approach when you know in advance which attributes your identity team will map. You create the attribute, give it a name that matches the claim key and a readable title, and set the data type. When SSO then delivers a claim whose key matches, Userlane populates the value on each user's profile as they sign in.

The second is auto-creation. If the identity provider sends a claim for an attribute that does not yet exist in Userlane, the attribute is created automatically and tagged as SSO-created. You do not have to create anything in advance, but auto-created attributes inherit the key name the identity provider uses, which is sometimes a long string or a URL rather than a readable label.

{% hint style="info" %}
**Matching rule.** Userlane matches on the attribute name (the key), not the title. A manually created attribute whose name matches the claim name in the SAML assertion receives the SSO value.
{% endhint %}

## Verify that attributes arrived

After a user has signed in through SSO, check that their attribute values came through.

{% stepper %}
{% step %}

#### Open the Company Users area

Go to **Settings** > **Company Users** in the portal.
{% endstep %}

{% step %}

#### Select a user who has signed in through SSO

Choose someone you know has completed SSO authentication since the attributes were mapped.
{% endstep %}

{% step %}

#### Review their attribute values

The profile shows each attribute with the value from the most recent sign-in. If an expected attribute is missing, confirm with your identity team that the claim is included in the SAML assertion and that the key name matches.
{% endstep %}
{% endstepper %}

## Set the refresh interval

SSO attributes update when Userlane retriggers the authentication flow for someone who is already signed in. The refresh interval controls how often that happens. Without it, attribute values only update on the next full sign-in, which may be days or weeks away for people who keep their browser open.

{% stepper %}
{% step %}

#### Open the refresh interval setting

Go to **Settings** > **Global settings** > **Browser Extension** and find the **SSO Refresh Interval** dropdown.
{% endstep %}

{% step %}

#### Choose an interval

Four options are available: disabled (no refresh at all), daily (every 24 hours), every other day (every 48 hours), and weekly (every 7 days). A shorter interval keeps values more current but triggers the SSO authentication prompt more frequently, which adds load to your identity provider.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
**Limitation: values depend on the authentication prompt.** The refresh works by showing the user the SSO authentication prompt, so values only update for people who see it. Users who have not triggered the prompt recently carry stale values. There is no background sync on the SSO path.

If attributes need to stay current without interrupting users, connect the same identity provider as an attribute source instead. Connectors refresh silently every 24 hours with no user-facing prompt. SSO and a connector can run side by side: SSO handles authentication, the connector handles attributes. See [Connect an attribute source](/administration/attributes/connect-an-attribute-source.md).
{% endhint %}

## Rename long attribute keys

Identity providers sometimes send attribute keys as long strings or URLs rather than readable names. A key like `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department` is correct but difficult to work with when building audiences.

{% stepper %}
{% step %}

#### Open the attribute settings

Go to **Settings** > **Company Attributes**.
{% endstep %}

{% step %}

#### Select the attribute to rename

Find the attribute with the long key and open it.
{% endstep %}

{% step %}

#### Change the title

Enter a short, readable title. The underlying name stays the same, so the SSO mapping continues to work. Only the label shown in the portal changes.
{% endstep %}
{% endstepper %}

## Relevant articles

{% content-ref url="/pages/gtcOzAVjL7zzv75As2Jd" %}
[Attributes](/administration/attributes.md)
{% endcontent-ref %}

{% content-ref url="/pages/heUmxS6HxlGKqCQSjqbs" %}
[Attribute sources](/administration/attributes/attribute-sources.md)
{% endcontent-ref %}

{% content-ref url="/pages/5RV9H7dUyIbkTHBrF8Av" %}
[Connect an attribute source](/administration/attributes/connect-an-attribute-source.md)
{% endcontent-ref %}

{% content-ref url="/pages/IkbYytjTIP1b0c4ZNCbM" %}
[End-user single sign-on](/deployment/rollout/end-user-single-sign-on.md)
{% endcontent-ref %}

## FAQ

<details>

<summary>Can SSO create attributes automatically?</summary>

Yes. When the identity provider sends a SAML claim for an attribute that does not yet exist in Userlane, the attribute is created automatically and tagged as SSO-created.

</details>

<details>

<summary>How often do SSO attributes update?</summary>

At the refresh interval configured in the portal: disabled, daily, every other day, or weekly. The update happens when Userlane retriggers the SSO authentication prompt for the user. Without a refresh, values only update on the next full sign-in.

</details>

<details>

<summary>What if attributes need to stay current without interrupting users?</summary>

Connect the identity provider as an attribute source. Connectors refresh silently every 24 hours with no user-facing prompt.

</details>

<details>

<summary>Can SSO and a connector run for the same identity provider?</summary>

Yes. SSO handles authentication and user registration. The connector handles attributes. They do not interfere with each other, and running both is the recommended approach when attribute freshness matters.

</details>

<details>

<summary>Why is an expected attribute missing from a user's profile?</summary>

The most common cause is that the claim is not included in the identity provider's SAML assertion mapping. Confirm with your identity team that the attribute is mapped. If it is mapped, check that the key name matches between the identity provider and Userlane.

</details>

[^1]: An identity provider (IdP) is the system that manages your organization's user accounts and sign-in, such as Microsoft Entra ID, Okta, or Google Workspace.

[^2]: A SAML assertion is a message the identity provider sends to Userlane during sign-in, carrying the user's identity and any attribute claims the identity team has mapped.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.userlane.com/administration/attributes/attributes-from-sso.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.