Single Sign-On (SSO) lets you log in once and access multiple services without entering your username and password again. For example, if your company uses SSO, you might log in to one system (like your email), and then automatically be able to access Starmind without logging in again.

How Does SAML 2.0 Fit In?

SAML 2.0 (Security Assertion Markup Language) is a popular way to make SSO work. It allows one system (called the Identity Provider or IdP) to confirm who you are and tell another system (called the Service Provider or SP) that you are allowed to use it.
• Identity Provider (IdP): This is where you log in (e.g., your company’s login system).
• Service Provider (SP): This is the system you want to use (in this case, Starmind)

How Do the Identity Provider and Service Provider Trust Each Other?

Before SSO can work, the IdP and SP need to trust each other. This trust is built through something called metadata files.

• Metadata File: This is like a digital “handshake” that tells both systems how to communicate securely.
• The IdP gives the SP a metadata file that includes:
  • A unique identifier for the IdP.
  • A link to where the SP should send login requests.
  • A public security certificate to verify messages from the IdP.
• The SP gives the IdP a metadata file that includes:
  • A unique identifier for the SP.
  • A link to where it will accept login responses.
  • A public security certificate to verify messages from the SP.

These metadata files act like a contract that both sides agree to before SSO is used.

What Happens When You Log In?

1. You try to access Starmind (the SP)
2. Starmind checks if you are already logged in – If not, it redirects you to your company’s IdP.
3. You log in at the IdP – e.g., with your work email and password.
4. The IdP confirms your identity and sends a response to Starmind (the SP) – This response is a secure message (called a SAML assertion).
5. Starmind (the SP) verifies the response using the metadata file – It checks that The response is from the trusted IDP and that the response hasn’t been tampered with (using the security certificate).
6. You get access to Starmind (the SP) – Without needing to enter another password.

Why Is This Secure?

• The metadata files ensure that only trusted systems can exchange login information.
• The security certificate prevents hackers from faking login responses.
• Your credentials are only entered once (at the IdP), reducing the risk of phishing.

Think of SAML SSO like an airport security check:

• Your passport (identity) is checked at the security gate (IdP).
• If verified, you get a boarding pass (SAML assertion).
• You then use this boarding pass to board a plane (access the service provider).
• The airline (SP) trusts the security check (IdP) because they have an agreement in place (metadata exchange).

How to set up Single Sign-On with Starmind

1. Request the SSO setup with the support team

Currently, the process isn’t fully automated. You need to submit a ticket via our Customer Service Portal to provide and request essential details (described below) for configuring SAML 2.0. This will notify your account manager and support team so they can initiate the setup process.

We provide you with the metadata file for the Service Provider (Starmind), which you can then pass on to your internal Identity Provider team. What the metadata file is and what it includes is outlined above. You can also download the metadata file yourself as outlined below Metadata files

2. Set up SSO with your internal Identity Provider team

1. Create a Dedicated SSO Group

• Request your internal Identity Provider (SSO) team to create a dedicated group, such as "Starmind". Provide them with a list of users, departments, or other relevant groups that should be included. It's best to start with a small test group to verify SSO functionality before rolling it out to a larger user base.

2. Grant Access to the Starmind Application

• Once the group is created, ask your SSO team to assign the "Starmind" group access to the Starmind application. This step ensures that only authorized users can log in via SSO.

Principal

In a SAML 2.0 Assertion, the <saml:Subject> element identifies the principal (usually a user) that the assertion is about. This is a core part of the assertion structure and typically includes information necessary for authentication and authorization.

We expect the principal identifier to be a NameID with the format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent. The identifier should be unique and not change over time. The NameId type should be "Persistent".

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_23995a40-0216-4ad5-a311-6764d28b7696" IssueInstant="2014-10-10T12:57:06.032Z" Version="2.0">
  <Subject>
    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">60bd7c0b-1118-48ed-8bae-e11b2a2e5921</NameID>
  </Subject>
</Assertion>

Claims

You can find the complete list of supported attributes by Starmind below.

Attributes marked as Used by Starminds Algorithms will increase the accuracy of Starmind. To get the best out of Starmind, those attributes need to be provided.

Attributes marked as Required for advanced analytics will allow you to get more insights into the application. We recommend providing those from the beginning.

Role Management

You can provide the roles within the SAML assertion. This will update the roles of the user on every login. By default, every user has the role user. This allows everyone to access the application. This means you don't have to provide the user role in the SAML assertion.

<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
  <AttributeValue>communication_admin</AttributeValue>
  <AttributeValue>content_admin</AttributeValue>
  <AttributeValue>settings_admin</AttributeValue>
  <AttributeValue>user_admin</AttributeValue>
  <AttributeValue>user_statistics_admin</AttributeValue>
</Attribute>

📘

Roles

If you want you can also group some roles in one attribute. E.g. having a role which is called "starmind_admin" for all the admin roles available.

3. Pass along the Identity Provider metadata file to Starmind

Use the ticket you created in step one to pass along your identity provider's metadata file (it has to be provided by our internal identity provider team). With this, we can complete the setup and activate Single Sign-On with SAML 2.0 for your Starmind network.

A good example of an Identity Provider metadata file can be found here: https://en.wikipedia.org/wiki/SAML_2.0#Identity_Provider_Metadata. It looks similar to this:

Metadata files

Service Provider metadata file

This is an example of the Service Provider Metadata file you get from us. You can easily distinguis the metadata files of the Service Provider and the Identity Provider by the xml tag <md:SPSSODescriptor ...> for service providers, respectively <md:IDPSSODescriptor ...>for identity providers.

<md:EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://auth.starmind.com/auth/realms/161"
  ID="ID_7c95b06b-a2f5-45d5-9d62-8cc30ccf539d">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
    AuthnRequestsSigned="true" WantAssertionsSigned="true">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:KeyName>sKWcVAjHGr5xVTnmte_iGjkceW68FygehQIZtP07tcI</ds:KeyName>
        <ds:X509Data>
          <ds:X509Certificate>
            MIIClTCCAX0CBgF1IcpbvzANBgkqhkiG9w0BAQsFADAOMQwwCgYDVQQDDAMxNjEwHhcNMjAxMDEzMTE0NjUxWhcNMzAxMDEzMTE0ODMxWjAOMQwwCgYDVQQDDAMxNjEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRbrzzvmZQ4dXFuY8vaKpmFuysbf5evAfkh2XIL4hE/ojY4yZyooMFDBKDRJGyNFb0Lw6ID/Tlsf2nmpByCfGUjyLNOZUvBOPPn0H8eo/pDKjdLr/Jb07BXtNIqiDiRMeo44Sh8kmmoiBqu0/7mHzRNyWFfnNnj1uZ7Gt53fRiYjR2szLlNNOOUuDpZlXov2Ls+B/tBK0cMgQcMoOz4/1XR4d0Gy3n/b6vKP/vgqREGdturUOrkCR8ZDIHkuioMwv/srQBRSSUzKvx6uosuaSH7n5k5EAdQSNaIYXUNADeNz3Ty+4IzAFR2aNTb3Z0FNhi/96YEQtdOI4XFzB4sl3dAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAFWov9K77gP49ll9P8XKSpsVfvRA417X5dLmWZEzyk9lA5pcTf7cs0c8sBQHKyFDBgey2qoVVfihPeVWCXMftxEeKOD5nV0RJrqQwj/9RBzYxX0iBm6rREuGOVNCcE7R5SKomhma4/SGaUX8/nteW7ZoKibs7N13k0PVPQWOYt0KQb7JNkvAb4s5KqgbYqou54OEKNKixgt8Aack1L4qc+Q3goCz25hlUQfIpnkqJ1gNZm/MR+/Ti6t5JtRq368X4CeZfZY9SfS7IcVqRYsiMKhnKFZOoeSS4KLyGpA7TKnq5Kt1PDnlaCZUehrNfvzfWP/vEbR/0hV6xUqnoemJBOk=</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://auth.starmind.com/auth/realms/161/broker/saml/endpoint" />
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://auth.starmind.com/auth/realms/161/broker/saml/endpoint" isDefault="true"
      index="1" />
    <md:AttributeConsumingService isDefault="true" index="1">
      <md:ServiceName xml:lang="de">askthebrain</md:ServiceName>
      <md:RequestedAttribute Name="country"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute Name="location"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute
        Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute Name="position"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute Name="company"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
      <md:RequestedAttribute Name="department"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Download the Service Provider metadata file

You can always download the latest version of the Service Provider metadata file from Starmind. The URL is specific to your Starmind network, but it looks like this:

https://auth.starmind.com/auth/realms/YOUR_REALM_ID/broker/YOUR_SAML_ALIAS/endpoint/descriptor

You need three things to replace in this example:

1. URL of our Authentication Service. Please find a list below with the correct URLs
2. The REALM_ID of your Starmind network. You can find this ID through the API. Just open a browser with this URL and search for "realm_id". https://YOUR_SUBDOMAIN.starmind.com/api/v2/settings. Don't forget to use your specific Starmind domain.
3. The SAML alias is by default "saml".

URL for Authentication Service

• Swiss data center: https://auth.starmind.com
• EU data center: https://auth-eu.starmind.com
• US data center: https://auth-us.starmind.com

Alternative terminology

SAML provides a mechanism to exchange authentication and authorization data between two trusting entities. In a generic SAML context, the entities are:

• The Asserting party (or SAML authority)
• The Relying party (or SAML requester)

In an SSO context, the Asserting party is the Identity Provider (IdP) and the Relying party is the Service Provider (SP). The Identity Provider is the customer's SAML federation server (ADFS etc.) and the Service Provider is the Starmind SaaS application.