SSO Integration using SAML2

Introduction

For SSO (Single Sign-On) integration, Innomesh acts as a Service Provider (SP) and can integrate with an identity provider (IdP) set up by your organisation. The most common use case is integrating with Active Directory or Entra ID using Security Assertion Markup Language 2.0 (SAML2).

Integration Steps

Step 1: Provide Your Organisation’s SAML Metadata

To get started, provide Innomate with your organisation’s SAML metadata. This is preferably supplied as a URL so that it can be dynamically retrieved, but providing it as a file is also acceptable.

Step 2: Configure Your Organisation’s IdP

Your IdP needs to be configured with the following values, which Innomate will supply:

1. Add relying party trust for AWS (required for some IdPs):

   https://signin.aws.amazon.com/static/saml-metadata.xml

   Reference: SAML identity providers — Amazon Cognito Developer Guide

2. Configure the SAML Audience (or Entity ID) for Innomesh Portals (provided by Innomate):

   urn:amazon:cognito:sp:<aws-region>_xxxxxxxxx

3. Configure the Assertion Consumer Service (ACS) URL (or Reply URL) for Innomesh Portals:

   https://<tenant>-<environment>.auth.<aws-region>.amazoncognito.com/saml2/idpresponse

Step 3: Configure SAML Assertion Attributes

Your IdP must be configured to return the following SAML assertion attributes:

Optional Step: Role-Based Access Control via memberof

memberof is a custom attribute Innomesh uses to map users to roles defined in its RBAC engine. Each value maps to a role, so the set of values is not fixed and is agreed per integration.

The default role identifiers are:

Multiple roles can be assigned by including multiple memberof attribute values in the SAML assertion:

<Attribute Name="memberof">
  <AttributeValue>Innomesh_admins</AttributeValue>
  <AttributeValue>Innoportal_admins</AttributeValue>
</Attribute>

In an Active Directory or Entra ID integration, groups can be mapped to memberof values, allowing administrators to control Innomesh user authorisation directly from their directory — simply by placing users into the relevant groups.

The Username (NameID) Attribute

Innomesh requires a NameID to be present in the SAML assertion. The Innomesh SP uses a stable, unique identifier from the assertion to provision and identify the federated user. Map this to a durable, single-token attribute — for example eduPersonPrincipalName, the user’s email, or a persistent NameID format.

The identifier used for the username must satisfy the SP’s validation rules — it must be present, unique, and contain no whitespace, and be no longer than 128 characters. Avoid mapping the username to a display name: human-readable display names typically contain a space, which the SP rejects, preventing sign-in. See the redirect-loop troubleshooting entry in the Frequently Asked Questions below.

Active Directory Group Mapping

For organisations using Active Directory, the recommended approach is to create AD groups that correspond to the memberof values:

• Create an AD group named Innomesh_admins and add users who require admin access to Room Manager.
• Create an AD group named Innoportal_admins and add users who require admin access to Portal.
• Create equivalent groups for _users level access as needed.

When a user authenticates, the IdP includes their AD group memberships in the SAML assertion’s memberof attribute, and Innomesh maps these to the appropriate access level.

Signing & Encryption

The Innomesh SP supports signed authentication requests and encrypted SAML assertions. Both are optional and agreed per integration. Where they are not required, a signed (but unencrypted) assertion delivered over TLS is fully supported and remains the default.

Encrypted Assertions

Where your organisation’s security policy requires the SAML assertion to be encrypted, the Innomesh SP can accept encrypted assertions. Innomate provides a provider-specific encryption certificate generated for your integration; your IdP encrypts each assertion to the public key in that certificate, and the SP decrypts it on receipt.

The following must be observed for encrypted assertions to be accepted:

Signed Authentication Requests

Where required, the Innomesh SP can sign the SAML authentication requests (AuthnRequests) it sends to your IdP, allowing your IdP to verify their integrity. This is an optional capability that is disabled by default and enabled only on request as part of the integration. If your organisation requires signed authentication requests, raise this with Innomate so it can be arranged and validated. Where it is enabled, your IdP must be configured to verify the signature using the SP signing certificate provided by Innomate; where it is not, no signature verification should be expected on inbound requests.

Certificates

Innomate can provide both a signing certificate and an encryption certificate on request. These are specific to your integration. A new certificate is issued annually; the underlying public key does not change between certificates, so existing configurations continue to work, but as a best practice keep the current certificate maintained in your IdP configuration to avoid interruption.

Useful Links

• AWS Cognito Federated Authentication with Azure AD / Entra ID
• SAML federation in Amazon Cognito using IdP-initiated SSO, request signing and encrypted assertions
• SAML signing and encryption — Amazon Cognito Developer Guide

Frequently Asked Questions

Can Innomate provide a signing certificate? Yes, on request. A signing certificate is used where signed authentication requests are in use, which is an optional capability enabled only on request as part of the integration (see Signed Authentication Requests). Where this is not required for your integration, a signing certificate is not needed.

Does Innomesh support encrypted SAML assertions? Yes. Innomate provides a provider-specific encryption certificate; your IdP encrypts each assertion to it and the SP decrypts it on receipt. The required algorithms and behaviour are set out under Encrypted Assertions. Note that once encryption is enabled, the SP rejects unencrypted assertions — so encryption must be applied to all assertions for the integration.

Does Innomesh require encrypted assertions? No. Encryption is optional. A signed assertion delivered over TLS is fully supported and is the default. Encryption is enabled where your organisation’s security policy requires it.

Will Innomesh be signing AuthnRequests? Not by default. The Innomesh SP supports signing the authentication requests it sends to your IdP, but this is an optional capability that is disabled unless specifically requested for your integration (see Signed Authentication Requests). Where it is enabled, your IdP must be configured to verify the signature with the SP signing certificate.

Does Innomesh support IdP-Initiated SSO? SP-initiated SSO is the default and strongly recommended flow. We recommend against IdP-initiated SSO: because the SP does not initiate the request, it cannot verify that it solicited the SAML response it receives, which removes the protection against request spoofing and cross-site request forgery (CSRF) that SP-initiated flows provide. Where IdP-initiated SSO is nonetheless required, raise this with Innomate so the integration can be assessed and configured appropriately. Reference: SAML session initiation — Amazon Cognito Developer Guide.

My IdP cannot support authorisation decisions using memberof — can Innomesh assign permissions locally? Yes. Innomesh has a full RBAC engine that can be used to set up user authorisation on the service side. Configuring authorisation on the IdP side is simply a convenience that lets customers manage users from a single place.

Does the Innomesh ACS use HTTP-POST binding? Yes. Reference: Adding SAML identity providers to a user pool — Amazon Cognito Developer Guide.

Does Innomesh expect a NameID in the SAML assertion? Yes. The NameID — or the attribute mapped to the username — must be present, unique, no longer than 128 characters, and contain no whitespace. See The Username (NameID) Attribute and the troubleshooting note below.

Why am I being redirected back to the SSO selection page each time I log in? A redirect loop means the SP could not complete sign-in from the SAML response. The most common causes, in order:

1. Assertion attributes set up incorrectly — refer to Step 3.
2. Username mapped to an unsuitable attribute — if the username is mapped to a value containing a space (e.g. a display name) or is empty, the SP rejects it. Map it to a stable, whitespace-free attribute (see The Username (NameID) Attribute).
3. Encryption mismatch — if encryption is enabled, the assertion must be encrypted with the correct algorithm and the provider-specific certificate (see Encrypted Assertions). An assertion encrypted with an unexpected algorithm, or not encrypted when the SP requires it, is treated as having no usable assertion.
4. Too many groups in memberof — each attribute has a hard limit of 2048 characters. Either reduce the number of groups exposed to Innomesh to only those required, or contact Innomate to disable the memberof feature and manage user roles directly within Innomesh instead.

Related Articles

• RBAC Authorisation Guide
• Administration Settings