Skip to main content
Identity Authority
Category: Federation & SSO

Attribute Statement

Also known as: SAML AttributeStatement, AttributeStatement element
Simply put

An Attribute Statement is the part of a SAML message that carries pieces of information about a user, such as their department, role, or group membership. It travels alongside the confirmation that the user has signed in, so the receiving application can learn details about who the user is. It is a way for one system to pass identity information to another during single sign-on.

Formal definition

In SAML 2.0, an AttributeStatement is one of the statement types that may appear within a SAML assertion. It supplies a set of attributes, typically expressed as name/value pairs such as department, role, or group membership, that the issuing identity provider associates with the assertion's subject. The AttributeStatement conveys identity-related data to a service provider and is distinct from the AuthnStatement, which asserts the fact and context of authentication; depending on configuration, an assertion may contain one or both. The specific attribute names, formats, and values are deployment- and profile-dependent, and receiving applications map these attributes to their own schema (for example, via configured attribute statements in the identity provider). Attribute values carried this way support downstream authorization decisions but the statement itself expresses attributes rather than making an authorization decision.

Why it matters

The Attribute Statement is the mechanism by which a SAML identity provider communicates identity-related data about a user to a service provider during federated single sign-on. Without it, a receiving application would learn only that authentication occurred (via the AuthnStatement) but would have no structured way to receive details such as department, role, or group membership. This data is what allows applications to personalize sessions and to feed downstream authorization decisions, although it is important to note that the Attribute Statement itself only conveys attributes and does not make any authorization decision.

Because attribute names, formats, and values are deployment- and profile-dependent, misalignment between what an identity provider emits and what a service provider expects is a common source of integration failures. If an application expects a group attribute under one name and the IdP sends it under another, the user may authenticate successfully yet be denied access or granted incorrect entitlements. Correctly configured attribute statements are therefore central to reliable SSO onboarding and to ensuring that the attributes used for access mapping are accurate and consistent.

The Attribute Statement also matters from a data-handling perspective: it carries identity information across a trust boundary between organizations or systems. Deployments should be deliberate about which attributes are released, since the statement can transmit profile elements, group information, or status fields beyond the minimum needed by the service provider. What is included is governed by IdP configuration rather than by the standard itself.

Who it's relevant to

IAM and SSO Engineers
Engineers configuring SAML federation define attribute statements on the identity provider and coordinate the corresponding attribute mappings on the service provider side. Getting attribute names and formats aligned across both parties is a frequent point of integration work, since these are deployment- and profile-dependent rather than standardized.
Security Architects
Architects designing federated access flows rely on the AttributeStatement to carry the identity data that downstream authorization logic consumes, while keeping in mind that the statement conveys attributes rather than making an authorization decision. They also govern which attributes cross the trust boundary between IdP and SP.
System Administrators
Administrators onboarding applications to SSO configure and troubleshoot attribute statements so that receiving applications receive the expected user details, such as department, role, or group membership, under the names those applications require.
Compliance and Governance Leads
Because attribute statements transmit identity-related data such as profile elements, group information, or status fields across systems, governance stakeholders have an interest in reviewing which attributes are released and ensuring that only necessary information is shared.

Inside Attribute Statement

AttributeStatement element
The XML element within a SAML 2.0 assertion that carries one or more attributes describing the authenticated subject. It is distinct from the AuthnStatement, which conveys authentication event information.
Attribute elements
Individual attributes contained within the statement, each typically identified by a Name and, depending on configuration, a NameFormat that indicates how the name should be interpreted (for example, an unspecified, URI, or basic format).
AttributeValue elements
The actual values associated with each attribute. A single attribute may carry multiple AttributeValue children, and values may be typed via xsi:type depending on the deployment and profile in use.
Subject association
The attribute statement describes the subject identified elsewhere in the assertion (in the Subject element). The statement itself conveys claims about that subject rather than establishing the subject's identity.
Common conveyed attributes
In most deployments, attributes such as email address, display name, group memberships, or role identifiers are carried to support downstream decisions. Which attributes appear depends entirely on the identity provider's configuration and any agreed attribute release policy.

Common questions

Answers to the questions practitioners most commonly ask about Attribute Statement.

Does an attribute statement authenticate the user?
No. An attribute statement carries claims about a subject (such as email, group memberships, or department), but it does not by itself authenticate the user. In SAML 2.0, authentication is asserted separately through an authentication statement, which conveys how and when the subject was authenticated. The attribute statement supplies descriptive attributes that a relying party typically consumes for authorization or personalization decisions, not for verifying identity. Keep the identification, authentication, and authorization steps distinct: the attribute statement primarily supports the later stages, not the act of verifying who the subject is.
Are the attributes in an attribute statement encrypted because the assertion is signed?
Not necessarily. Signing and encryption are separate protections. A signed SAML assertion provides integrity and origin authentication, meaning a relying party can detect tampering and confirm the issuer, but signing does not conceal the attribute values. If confidentiality of attributes such as personal data is required, SAML 2.0 supports encrypting assertions or specific attributes (for example via EncryptedAssertion or EncryptedAttribute), and transport-level protection such as TLS may also apply depending on configuration. Treat a signed-but-unencrypted attribute statement as readable in transit by anyone who can observe it outside a protected channel.
Where in a SAML assertion does the attribute statement appear, and how is it structured?
In a SAML 2.0 assertion, the attribute statement is one of several statement types the assertion element can contain, alongside authentication and authorization decision statements. It typically holds one or more attribute elements, each with a name and one or more attribute values, and often a name format that tells the relying party how to interpret the attribute name. Depending on the deployment and profile, an assertion may include an attribute statement, an authentication statement, or both. Consult the specific SAML 2.0 profile and your provider's metadata to confirm which statements are expected.
How should a service provider decide which attributes to request in an attribute statement?
In most deployments, scope the requested attributes to what the relying party actually needs for authorization, provisioning, or personalization, following data minimization principles. Coordinate the attribute names and name formats with the identity provider through metadata and, in some setups, an attribute consuming service definition so both sides agree on naming. Avoid pulling large group or entitlement sets into every assertion if only a subset drives access decisions, since oversized statements can complicate token handling and increase exposure of sensitive data. The exact mechanism for requesting or filtering attributes varies by vendor and profile.
How do attribute statement values relate to access control decisions at runtime?
Attribute statement values commonly feed authorization logic, but the relying party still performs the access decision itself. In an ABAC model, attributes such as department or clearance can be evaluated by a policy decision point against policy; in an RBAC context, a group or role attribute may map to a local role. The attribute statement is a source of subject attributes, comparable to a policy information point input, rather than a decision in its own right. How values are mapped, trusted, and combined with other sources depends on your policy engine and configuration.
What should be validated before trusting attributes from an incoming attribute statement?
At minimum, validate the assertion's signature to confirm integrity and issuer, check that the assertion is within its validity window, and confirm the intended audience and subject confirmation conditions per the SAML 2.0 processing rules. Beyond protocol validation, apply local trust rules: map attribute names and name formats deterministically, decide which attributes you will honor from a given issuer, and avoid over-trusting values that could drive privilege escalation. Whether attributes are further encrypted or filtered depends on your configuration and the agreement with the identity provider.

Common misconceptions

The attribute statement authenticates the user.
Authentication in a SAML 2.0 assertion is conveyed by the AuthnStatement, not the AttributeStatement. The attribute statement carries claims about an already-identified and authenticated subject; it does not itself verify who the subject is.
Attributes in a SAML assertion are confidential because the assertion is signed.
Signing provides integrity and origin authentication, not confidentiality. Unless the assertion or elements are also encrypted (for example via EncryptedAssertion or EncryptedAttribute, depending on profile and configuration), attribute values may be readable in transit or in logs. Signing is not the same as encryption.
Attributes released in the statement automatically determine what the user can do.
The attribute statement supplies attributes; it does not perform authorization. Attributes such as group or role values may feed an authorization decision at the relying party (for example in RBAC or ABAC evaluation), but the enforcement decision is made by the service provider or a policy decision point, not by the attribute statement itself.

Best practices

Release only the attributes each relying party actually requires, applying a minimal attribute release policy rather than sending all available attributes by default.
Encrypt sensitive attributes (for example via EncryptedAttribute or EncryptedAssertion) where confidentiality is required, since signing alone provides integrity but not confidentiality.
Agree on and document attribute Names and NameFormats with each relying party so that both sides interpret attribute identifiers consistently across the federation.
Treat attributes as claims about an already-authenticated subject and keep attribute release logically separate from the authentication event conveyed in the AuthnStatement.
Do not embed authorization decisions in the attribute statement; instead pass the attributes needed for the relying party or its policy decision point to make access decisions (for example RBAC or ABAC evaluation).
Validate and normalize incoming attribute values at the relying party before using them, since values, cardinality, and typing can vary by identity provider and configuration.
Application Security Isn’t Optional Anymore.