> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/federation/saml-identity-provider/saml-identity-provider-reference.md).

# Every SAML identity provider attribute, with its shipped default

Every AUTH\_ATTRIBUTE key on a SAML identity provider, with its Webconsole label, shipped default, binding property and release.

## What this covers

The complete attribute set behind [OpenIAM as a SAML identity provider](/administration-guide/federation/saml-identity-provider.md). These are `AUTH_ATTRIBUTE` rows with `PROVIDER_TYPE='SAML_PROVIDER'`. The `AUTH_ATTRIBUTE_ID` is the value you would see in `AUTH_PROVIDER_ATTRIBUTE` and the value each field is stored under; the **Property** column is the key that binds that field to its ID, and it is fixed.

Nothing on screen shows you an attribute's ID, so these tables are the mapping between what you set and what is stored. Four of the IDs are bare numbers — `1` to `4` — for historical reasons: they are the oldest attributes and were never renamed.

## Identity of the trust

| ID                 | Label                  | Required | Shipped default | Property                                                   |
| ------------------ | ---------------------- | -------- | --------------- | ---------------------------------------------------------- |
| `1`                | Request Issuer         | **Y**    | —               | `org.openiam.idp.provider.saml.attribute.requestIssuer.id` |
| `2`                | Response Issuer        | N        | —               | `...responseIssuer.id`                                     |
| `3`                | Assertion Consumer URL | **Y**    | —               | `...acs.id`                                                |
| `4`                | Audiences              | N        | —               | `...audiences.id`, `DATA_TYPE='listValue'`                 |
| `METADATA_EXPOSED` | Metdata Exposed        | N        | —               | `...metadataExposed.id`, `booleanValue`                    |

All five have shipped since 3.0.0.1. `Audiences` began life as `singleValue` and was corrected to `listValue` twice, in 4.1.0.0 and again in 4.2.0.0, so a long-lived database may need that value re-entered as a list — the symptom is a provider that refuses to hold a second audience. The `METADATA_EXPOSED` label misspells "Metadata"; that typo is shipped and is what you will see on the form.

## Signing, digest and canonicalization

| ID                          | Label                          | Shipped default                                     | Property                                                | Since    |
| --------------------------- | ------------------------------ | --------------------------------------------------- | ------------------------------------------------------- | -------- |
| `IDPSignatureAlgorithm`     | Signature Algorithm            | `http://www.w3.org/2001/04/xmldsig-more#rsa-sha384` | `org.openiam.saml.idp.signature.algorithm.attribute.id` | 4.0.0.0  |
| `IDPCanonicalAlgorithm`     | Canonicalized Algorithm        | `http://www.w3.org/2001/10/xml-exc-c14n#`           | `...cannonical.algorithm.attribute.id`                  | 4.0.0.0  |
| `IdpDigestAlgorithm`        | Digest Algorithm               | `http://www.w3.org/2001/04/xmldsig-more#sha384`     | `...digest.algorithm.attribute.id`                      | 4.0.0.0  |
| `IDPWantAssertionsSigned`   | IDP Sign Assertions            | —                                                   | `...want.assertions.signed`                             | 4.0.0.0  |
| `IDPWantResponseSigned`     | IDP Sign Response              | —                                                   | `...want.response.signed`                               | 4.2.1.14 |
| `IDPWantAuthnRequestSigned` | IDP Want Authn Requests Signed | —                                                   | `...want.authn.requests.signed`                         | 4.0.0.0  |

**The signature and digest defaults are SHA-384, and a large number of service providers reject that.** `rsa-sha384` and `#sha384` are the shipped defaults, deliberately so since 4.0.0.0 — the field's own description invites you to change it. But `rsa-sha256` / `#sha256` is what most partners publish support for. Read the SP's metadata `SigningMethod` and `DigestMethod` elements and set both attributes explicitly; then confirm what you are actually sending by fetching `/idp/saml2/idp/metadata/<PROVIDER_ID>` and reading the algorithm URIs out of it.

Note the label reads *"IDP Sign Assertions"* for `IDPWantAssertionsSigned` and *"IDP Sign Response"* for `IDPWantResponseSigned`. As an **IdP**, these control what OpenIAM signs on the way out, not what it wants to receive, and the attribute IDs are misleadingly named. `IDPWantAuthnRequestSigned` is the one that genuinely means "want" — whether OpenIAM requires the SP's `AuthnRequest` to be signed. **IDP Sign Response** arrived only in 4.2.1.14; on an earlier release the field is absent and you cannot sign the response separately from the assertion.

## NameID and authentication context

| ID                     | Label                              | Shipped default                                          | Property                                                   |
| ---------------------- | ---------------------------------- | -------------------------------------------------------- | ---------------------------------------------------------- |
| `NameIdFormat`         | Name ID Format                     | `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` | `...attribute.nameIdFormat.id`                             |
| `AuthnContextClassRef` | Authentication Context Class       | `urn:oasis:names:tc:SAML:2.0:ac:classes:Password`        | `...attribute.authncontextclassref.id`                     |
| `NameQualifier`        | Name Qualifier                     | —                                                        | `...attribute.nameQualifier.id`                            |
| `SPNameQualifier`      | SP Name Qualifier                  | —                                                        | `...attribute.spNameQualifier.id`                          |
| `IDPNameIDResolver`    | IDP Name ID Resolver Groovy Script | —                                                        | `org.openiam.saml.idp.saml.name.id.resolver.groovy.script` |
| `SignLoginId`          | —                                  | —                                                        | `...attribute.signLoginId.id`                              |

Both defaults have shipped since 3.0.0.1. The NameID format default is the **SAML 1.1** email URN, not the 2.0 one — correct and widely accepted, but a partner whose metadata specifies `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` needs it changed. `AuthnContextClassRef` defaults to `...ac:classes:Password`, which is an accurate claim for a password sign-in and an inaccurate one once you add MFA; some SPs make authorization decisions on it.

When `NameIdFormat` is set, OpenIAM uses it in preference to anything it would otherwise derive, so the field is the control and the resolver script is the escape hatch. Select `IDPNameIDResolver` only when the standard mapping cannot produce the required value, and make sure the script returns something stable and unique. Read the `Format` attribute of the `NameID` element in a SAML tracer to confirm which one won.

## Encryption

| ID                             | Label                                            | `DATA_TYPE` as declared | Property                                        |
| ------------------------------ | ------------------------------------------------ | ----------------------- | ----------------------------------------------- |
| `IDPSendEncryptedAssertion`    | IDP Send EncryptedAssertion                      | `singleValue`           | `org.openiam.saml.idp.saml.assertion.encrypted` |
| `IDPEncryptedAssertionDataAlg` | IDP EncryptedAssertion Data Encryption Algorithm | `booleanValue`          | `...encrypted.algorithm.data`                   |
| `IDPEncryptedAssertionKeyAlg`  | IDP EncryptedAssertion Key Encryption Algorithm  | `booleanValue`          | `...encrypted.algorithm.key`                    |

All three have shipped since 4.0.0.0, and none of them has a default — an untouched provider encrypts nothing. Enabling encryption without the SP's correct certificate makes the assertion unreadable and produces no error on the OpenIAM side, so test on a non-production trust with a rollback path.

{% hint style="info" %}
**These three attributes are the only encryption controls, and they are outbound-only.** They govern what this IdP encrypts on the way out. There is no corresponding `SAML_SP_PROVIDER` attribute for encrypted assertions at all: the SP-side attribute rows cover signing, bindings, relay state, chaining, NameID policy and a post-processor, and nothing else — so an inbound encrypted assertion is not configured with a pair of algorithm fields the way an outbound one is. If your question is about **decrypting** an assertion someone else's IdP sent you, it turns on that provider's key material and is answered on [OpenIAM as a SAML service provider](/administration-guide/federation/saml-service-provider.md).
{% endhint %}

{% hint style="info" %}
**Three IdP attributes are declared with the wrong `DATA_TYPE`, and no release has corrected it.** `IDPEncryptedAssertionDataAlg` and `IDPEncryptedAssertionKeyAlg` hold XML-Encryption algorithm URIs, and `IDPNameIDResolver` holds a Groovy script ID — yet all three are declared `DATA_TYPE='booleanValue'`. Meanwhile `IDPSendEncryptedAssertion`, which *is* a boolean, is declared `singleValue`. The values you enter are stored and read as strings either way, so the fields work. The consequence is only for anyone reading `AUTH_ATTRIBUTE` programmatically, and it is not visible from the console: look at the control the form actually renders rather than trusting the declared type.
{% endhint %}

## Logout, relay state, chaining and post-processing

| ID                           | Label                                 | Property                                                  | Since   |
| ---------------------------- | ------------------------------------- | --------------------------------------------------------- | ------- |
| `SPLogoutURLForIDP`          | Single-Logout URL of Service Provider | `org.openiam.saml.idp.attribute.logout.url.id`            | 4.0.0.0 |
| `IDPLogoutMethodBinding`     | IDP Logout Method Binding             | `org.openiam.saml.idp.saml.logout.binding`                | 4.0.0.0 |
| `IDPStaticRelayState`        | IDP Static Relay State                | `...relay.state.static.value`                             | 4.0.0.0 |
| `IDPRelayStateGenerator`     | IDP Groovy Relay State                | `...relay.state.groovy.script`                            | 4.0.0.0 |
| `IDPChainingEnabled`         | IDP Chaining Enabled                  | `...chaining.enabled`, `booleanValue`                     | 4.0.0.0 |
| `SAMLIdpGroovyPostProcessor` | Post Processor Groovy Script          | `org.openiam.idp.provider.groovy.post.processor.id`       | 3.3.3.0 |
| `IdpProtectedBy2FA`          | Protect by 2FA                        | `...protected.by.2FA`, `booleanValue`, **`REQUIRED='Y'`** | 4.1.8.0 |

None of these has a default in its `AUTH_ATTRIBUTE` row. `IdpProtectedBy2FA` is the exception that matters: it is `REQUIRED='Y'`, and when it arrived in 4.1.8.0 every `SAML_PROVIDER` that already existed was given the value `false` rather than being left empty. **So the effective default is `false`** — existing SAML applications were not retro-fitted with a second factor. The field's own description limits it further, to *"In case it's configured for used Content Provider"*: ticking it demands that the content provider serving the SSO endpoint actually offers a second factor. Open each SAML provider and read the checkbox; there is no list view that shows it.

Only `SAML_PROVIDER` and `SAML_SP_PROVIDER` can be chained; no other provider type offers the field. Use chaining only for an intentional multi-provider chain, and test the loop and failure cases.

What relay state resolves to, what a script inherits, and which base class to extend are on [OpenIAM as a SAML identity provider](/administration-guide/federation/saml-identity-provider.md#what-relay-state-resolves-to-and-what-a-script-can-change).

## Related

* [OpenIAM as a SAML identity provider](/administration-guide/federation/saml-identity-provider.md) — the procedure these attributes configure
* [OpenIAM as a SAML service provider](/administration-guide/federation/saml-service-provider.md) — the SP-side attribute set
* [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — the four `SAML_IDP_*` actions

*Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.*


---

# 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.openiam.com/administration-guide/federation/saml-identity-provider/saml-identity-provider-reference.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.