SAML IdP

Configuration reference for the SAML identity provider authenticator in Fortified ID Access

To learn more about how Fortified ID Access supports SAML, please click LINK.

Overview

Fortified ID Access can acts as a SAML 2 Identity provider (IdP). This is the first point of contact for a SAML SP. No identification is done by the SAML IdP, that is done by credential validators associated with the SAML IdP.

Configuration

Common Authenticator configuration can be found here.

Re-authentication is required when the incoming AuthnRequest has ForceAuthn=true, when the authenticator-level force_re_auth property is true, when force_re_auth is true in the IdP assertion configuration selected for the calling SP, or when the active SAML application or SAML profile requires it. These settings use OR semantics, so a value of false cannot disable a requirement from another source. An exact IdP target_sp match takes precedence over the "*" wildcard configuration.

Properties
Example

Name	Description	Default value	Mandatory
`force_re_auth`	Require re-authentication for every SP handled by this IdP. An incoming `ForceAuthn=true` or an SP-specific requirement still applies when this property is `false`.	`false`	false
`idp`	Value of the entity id when issuing the assertion.	N/A	true
`assertion_config`	Optional list of allowed SPs and their IdP assertion settings. Omit it or use `[]` to use metadata trust and SAML application settings. A nonempty list remains the allowlist; metadata does not admit SPs outside it. See SP trust and metadata fallback.	`[]`	false
`unsolicited_target_sp`	Entity id of SP used for unsolicited authentication.	N/A	false

{
"id": "auth00",
"type": "SAMLIDP",
"config": {
    "context_path": "/test/authn/chain",
    "base_path": "/test/authn",
    "force_re_auth": false,
    "idp": "aandrenidp",
    "chain": [{
        "id": "auth01",
        "required": true
    }],
    "assertion_config": [{
        "target_sp": ["https://sp.example.org/shibboleth"],
        "force_re_auth": true,
        "pre_assertion_pipe": "auhtZPipe",
        "encrypt_assertion": true,
        "encryption_algorithm": "http://www.w3.org/2001/04/xmlenc#aes256-cbc",
        "sign_response": false,
        "sign_assertion": true,
        "send_failed_response": false,
        "name_id_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",
        "nameid_parameter": "givenName",
        "additional_attribute_parameter": ["givenName", "sn", "objectClass"],
        "auth_context_parameter": "AuthnContextClassRef"
    }, {
        "target_sp": ["*"],
        "force_re_auth": false
    }]
}
}

SP trust and metadata fallback

The IdP's assertion_config is an array. It controls which SPs may use the IdP and supplies IdP-side assertion settings:

Nonempty array: Only SPs matched by target_sp are allowed. An exact entity ID match takes precedence over "*". An SP outside this list is rejected even if its metadata is loaded.
Omitted or []: Access uses the loaded SAML application metadata to establish trust. The calling entity ID must have usable SP metadata and an associated application configuration. Assertion settings come from the application or its selected SAML profile, with built-in defaults where applicable.

Both modes require usable SP metadata. Entity filters, IdP restrictions, signature validation, and checks of the assertion consumer service (ACS) destination continue to apply. A wildcard does not allow an unknown SP or bypass these checks.

With metadata fallback, send_failed_response is false: an authentication failure does not send a SAML failure response to the SP. With a nonempty list, the selected IdP entry continues to control this setting.

To use metadata trust, configure the SP through the SAML module's metadata entries, either directly or through the existing samltrust include. The following IdP example assumes that user_authentication is an existing authenticator and that the IdP and SP metadata are already configured:

{
  "id": "saml_idp",
  "type": "SAMLIDP",
  "config": {
    "context_path": "/saml/authn/login",
    "base_path": "/saml/authn",
    "idp": "https://idp.example.org",
    "chain": [
      {
        "id": "user_authentication",
        "required": true
      }
    ],
    "assertion_config": []
  }
}

Omitting the IdP's assertion_config property has the same effect as []. A nonempty list containing no target_sp values, such as [{}] or [{"target_sp": []}], is rejected during initialization.

Existing valid lists keep their trust and assertion-setting behavior. Removing a list changes the trust boundary to the loaded, filtered metadata and removes its IdP-side settings. Before switching an existing integration, review the allowed entities, configure the required assertion settings on the application or profile where supported, and verify the resulting SAML response. Keep an IdP entry if the integration requires send_failed_response=true. See application assertion configuration for the difference between an omitted application object and {}.

Name	Description	Default value	Mandatory
`target_sp`	Must include at least one SP entity id. The id must be loaded and known to the system. Use `"*"` to catch all SP entity ID's.	N/A	true
`force_re_auth`	Require re-authentication for SPs matched by this assertion configuration. An exact `target_sp` match takes precedence over the wildcard configuration. This value cannot disable global `force_re_auth` or incoming `ForceAuthn=true`.	`false`	false
`pre_assertion_pipe`	ID of pipe to execute before issuing assertion. Not required.	N/A	false
`sign_response`	Should SAML assertion be signed. Signing is performed using http://www.w3.org/2001/04/xmldsig-more#rsa-sha256	`true`	false
`sign_assertion`	Should SAML assertion be signed. Signing is performed using http://www.w3.org/2001/04/xmldsig-more#rsa-sha256	`false`	false
`encrypt_assertion`	Should assertion be encrypted. Requires encryption certificate in SP metadata.	`false`	false
`encryption_algorithm`	Optional XML Encryption data encryption algorithm for encrypted assertions. If omitted, Access first uses a compatible `EncryptionMethod` from SP metadata when present, otherwise the built-in default is used. Use `http://www.w3.org/2001/04/xmlenc#aes256-cbc` when an SP requires AES-256-CBC.	N/A	false
`nameid_parameter`	Attribute where value of nameID is located.	N/A	false
`name_id_format`	Format of nameID attribute.	`"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"`	false
`additional_attribute_parameter`	List of parameter names where additional attributes is located.	N/A	false
`auth_context_parameter`	Attribute where value of auth context ref is located.	`"AuthnContextClassRef"`	false
`hokap_parameter`	Attribute where value of certificate is located. PEM format is expected. The public key is extracted from the certificate and added to the KeyValue element in the assertion. Only RSA public keys are supported.	N/A	false
`send_failed_response`	If pipe fails should a SAML response be sent back to the sp.	`false`	false
`custom_identifier`	Identifier used in event logging to differentiate event logg entries.	N/A	false

"assertion_config": [{
    "target_sp": ["https://sp.example.org/shibboleth"],
    "force_re_auth": true
}, {
    "target_sp": ["*"],
    "force_re_auth": false
}]

Logging

On authentication request event is logged containing following:

WEB_100103("Received authentication request")
IDENTIFIER (user traceid)
AUTHENTICATOR_ID (config id + display_name if present)
SOURCE_SERVICE_NAME (entity id calling SAML SP)
SOURCE_ADDRESS (user IP address)
CUSTOMER_IDENTIFIER (if configured)

On a successful authentication event is logged containing following:

WEB_100101
IDENTIFIER (user traceid)
AUTHENTICATOR_ID (config id + display_name if present)
SOURCE_SERVICE_NAME (entity id of target SAML SP)
SOURCE_ADDRESS (user IP address)
CUSTOMER_IDENTIFIER (if configured)

On a failed authentication event is logged containing following:

WEB_100102
IDENTIFIER (user traceid)
AUTHENTICATOR_ID (config id + display_name if present)
SOURCE_SERVICE_NAME (entity id of target SAML SP)
SOURCE_ADDRESS (user IP address)
CUSTOMER_IDENTIFIER (if configured)

SLO - Single logout

By default saml slo endpoints are added to the metadata template. Both POST & Redirect bindings are supported and will be injected into the metadata when requested.

Data sent to PIPE

All data put into the shared authentication state along with the HTTP headers are exposed and sent into the pipe.

Data put into the state by this authenticator is:

SAMLRequest - mainly for internal use
requestedAuthnContextClassRefs - Multi value property of the "RequestedAuthnContext" -> "AuthnContextClassRef" if any.
spEntityID - entityID of the "calling" SP .
A subset of the sent request-headers from user-Agent.
All data returned from the assertion pipe

Expected data from PIPE

In order to use data from PIPE the response must contain one item. All data from that item will be available when creating SAML assertion.