Skip to main content

Reference

In this section, you'll find a detailed explanation of the available options for setting up an Identity Provider (IDP) or Service Provider (SP).

General Information​

  • Name: This is the provider's required name. It will be displayed in the list of providers and used when referencing the provider in other Monokee configurations. You have the option to replace the current name with a more user-friendly one, by default the name is composed as follows: <(idp|sp)>@<provider_id>.

  • Entity ID: This is the entity ID ot the provider. Entity ID is a unique identifier for a SAML entity, which can be a Service Provider (SP) or an Identity Provider (IDP). The entity ID is used to identify the SAML entity to other entities that interact with it in a SAML-based Single Sign-On (SSO) system. The default entity ID is composed as follows: https://<(new.monokee.com/<domain_id>|<domain-custom-fqdn>)>/<(idp|sp)>/saml/2.0/<provider_id>.

  • Issuer format: This is the format ot the issuer. The Format attribute is used to indicate the type of identifier being used for the issuer. Allowed values are:

    • urn:oasis:names:tc:SAML:2.0:nameid-format:entity: This value indicates that the issuer's name identifier is an entity identifier, which is a unique identifier for the SAML entity that is making the assertion.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent: This value indicates that the issuer's name identifier is a persistent identifier, which is an identifier that is unique to the individual and is maintained over time.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient: This value indicates that the issuer's name identifier is a transient identifier, which is an identifier that is only used for the duration of a single SAML exchange.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress: This value indicates that the issuer's name identifier is an email address.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified: This value indicates that the format of the issuer's name identifier is unspecified.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName: This value indicates that the issuer's name identifier is an X.509 subject distinguished name.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName: This value indicates that the issuer's name identifier is a Windows domain qualified name.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos: This value indicates that the issuer's name identifier is a Kerberos principal name.

  • Name qualifier of the issuer: It's the NameQualifier attribute in the Issuer element of a SAML assertion, it specifies the security or administrative domain that qualifies the name. This can be useful in situations where multiple entities with the same Issuer value are present in the SAML infrastructure. In this case, the NameQualifier attribute can help to distinguish between the different entities.

  • Name ID format: This multi-value field reports the supported NameID format by the provider. Allowed values are:

    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent: This format indicates that the NameID is a persistent identifier that is guaranteed to be unique within the scope of the IDP and SP involved in the SAML exchange. This is often used in cases where the SP needs to maintain a long-term relationship with the user or entity, even if the user's identifier changes over time.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient: This format indicates that the NameID is a transient identifier that is not guaranteed to be unique over time, but is unique within the scope of the current SAML exchange. This is often used in cases where the SP does not need to maintain a long-term relationship with the user or entity. If this format is chosen, the Subject Mapping Rule is not available and a random uuid will be used as user identifier.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress: This format indicates that the NameID is an email address that uniquely identifies the user or entity. This is often used in cases where the user's email address is their primary identifier.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified: This format indicates that the NameID format is not specified.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName: This format indicates that the NameID is an X.509 subject name that uniquely identifies the user or entity. This is often used in cases where digital certificates are used for authentication.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName: This format indicates that the NameID is a Windows domain-qualified name that uniquely identifies the user or entity.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos: This format indicates that the NameID is a Kerberos principal name that uniquely identifies the user or entity. This is often used in cases where Kerberos is used for authentication.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:entity: This format indicates that the NameID represents a SAML entity, such as an IDP or an SP. This is often used in cases where the NameID is used to identify the entity involved in a SAML exchange.

  • Display metadata: This checkbox makes possible to download the provider metadata from url also for not authenticated request. The download url is composed as follows: https://<(new.monokee.com/<domain_id>|<domain-custom-fqdn>)>/<(idp|sp)>/saml/2.0/<provider_id>/metadata?signed=<(true|false)>&sigAlg=<(http://www.w3.org/2000/09/xmldsig#rsa-sha1|http://www.w3.org/2001/04/xmldsig-more#rsa-sha256|http://www.w3.org/2001/04/xmldsig-more#rsa-sha384|http://www.w3.org/2001/04/xmldsig-more#rsa-sha512)>

Organization​

The SAML 2.0 metadata Organization object is an optional element within a SAML 2.0 metadata XML document that provides information about the organization responsible for the SAML entity described in the metadata. It contains the following sub-elements that are language-value pairs:

  • Organization Name: The required name of the organization.
  • Organization Display Name: The required display name of the organization.
  • Organization Url: The optional URL of the organization's website.

Contact person​

The SAML 2.0 metadata Contact Person object is an optional element in a SAML 2.0 metadata XML document that provides contact information for the entity described in the metadata. The Contact Person element contains the following sub-elements:

  • Contact Type: The type of contact, such as technical or administrative. Allowed values are: technical, support, administrative, billing, other.
  • Company: The name of the contact's company.
  • Firstname: The contact's firstname.
  • Surname: The contact's surname.
  • E-mail Address: The contact's email address.
  • Telephone Number: The contact's telephone number.

Signing Options​

  • Available options for IDP are:
    • IDP requires signed authentication requests: If enabled, the IDP mandates that incoming authentication requests must be signed; if not, the validation process will fail.
  • Available options for SP are:
    • SP signs authentication requests: If enabled, the SP will sign the outgoing authentication requests.
    • SP requires signed assertions: If enabled, the SP mandates that incoming assertions in SAML Responses must be signed; if not, the validation process will fail.

Signature​

This is a list of key-pairs that are valid for the provider. The provider will use the first element of the list to sign messages before sending according to Signing Options. The ability to enter more than one key pair is given to ensure key-rotation functionality. Two element must be configured:

  • Certificate: This is the certificate that will be inserted in the provider metadata and shared with the parties involved in the federation process.
  • Private Key: This is the private key used to sign SAML message. It must be in PKCS1 format.

Single logout services​

The Single Logout Service (SLO) is the endpoint where one provider sends to an other provider the Logout requests and responses. Different protocols could be use to transport logout request and response, these methods are called bindings. A provider has the flexibility to define one or multiple SLS endpoints, each of which can be associated with a specific binding protocol. Each endpoint is fully defined by three values:

  • Binding: Is the protocol supported by the endpoint. The supported values from Monokee are:

    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST: This binding is used for sending SAML Logout Request or Response messages. To send these messages, they are first encoded in Base64 format and included as the value of a parameter in the body of an HTTP POST request. The content type of this request is usually set to application/x-www-form-urlencoded, which allows for the message to be transmitted as key-value pairs in the request body.
    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect: This binding is used for sending SAML Logout Request or Response messages. To send these messages, they are first deflated and encoded in Base64 format, and then included as part of the URL parameters in the Location header of a 302 HTTP response, allowing for the messages to be transmitted via HTTP Redirect.

  • Location: Is the the URL of the endpoint where the provider expects to receive the Logout Request.

  • Response location: Is the the URL of the endpoint where the provider expects to receive the Logout Response.