Federation

Web SSO

Introduction to Identity Federation

What is Identity Federation?

A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems. The federation is a system of trust between two parties for the purpose of authenticating users and sharing information needed to authorize their access to resources.

A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.

It is related to single sign-on (SSO), in which a user's single authentication ticket, or token, is trusted across multiple IT systems or even organizations. SSO is a subset of federated identity management, as it relates only to authentication and is understood on the level of technical interoperability and it would not be possible without some sort of federation.

Federated identity is related to single sign-on (SSO), in which a user's single authentication ticket, or token, is trusted across multiple IT systems or even organizations. SSO is a subset of federated identity management, as it relates only to  authentication and is understood on the level of technical interoperability and it would not be possible without some sort of federation.

With the identity federation, we get to separate the applications and, the login and get permissions process. Currently, there are two mainstream identity federation standards: SAML and OpenID-Connect. 

The authentication service is responsible for identifying users and passing the information to the applications.

Which protocols are supported by Soffid?

 

SAML (Security Assertion Markup Language)

It is an identity federation protocol, born in 2001 and published in 2005. The design of SAML is highly secure and based on the technologies used at the beginning of this century. It uses XML tokens, signed and optionally encrypted using XMLdSig standard, and uses SOAP as its transport protocol.

SAML is an important component of many SSO systems that allow users to access multiple applications, services or websites from a single login process. SAML allows sharing security credential across systems.

Visit the SAML Chapter for more information.

OpenID-Connect

It is identity layer on top of the OAuth 2.0 protocol. OpenID-Connect is based on most modern protols. It uses JSON tokens, signed and optionally encripted using JWT standard, and uses simple REST as its transport protocol.

Sometimes referred as OpenID, must not be confused with an older and deprecated standard named OpenID.

Visit the OpenID-Connect Chapter for more information.

The main differences between SAML and OpenID-connect

https://en.wikipedia.org/wiki/Federated_identity


SAML

SAML

SAML (Security Assertion Markup Language)

Introduction

Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

It is an identity federation protocol, born in 2001 and published in 2005. The design of SAML is highly secure and based on the technologies used at the beginning of this century. It uses XML tokens, signed and optionally encrypted using XMLdSig standard, and uses SOAP as its transport protocol.

SAML is an important component of many SSO systems that allow users to access multiple applications, services or websites from a single login process. SAML allows sharing security credential across systems.

SAML establishes indirect communication with applications through the browser.




saml-logo.png
http://saml.xml.org/
https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
SAML

SAML architecture

Introduction

SAML is the most complete, secure, and mature solution to get identity federation. SAML defines three main kinds of servers:

For now, we will focus on the single log-in and single log-out use cases, but be in mind that SAML defines much more use cases.

Communication is done through the browser

Single Log-in

The single log-in is usually initiated by the application server. The typical UML use case is as follows:


Description

1. The user’s browser tries to get a web page from the service providers.

2. The service provider wants to authenticate the user identity. To get this, builds an AuthenticationRequest document. It is an XML document that includes the server name and time and date. This XML document is signed using its private key and optionally encrypted using the identity provider public key. Both keys are published by the federation metadata server.

3. The service provider generates an HTML page that automatically posts the AuthenticationRequest document to the identity provider.

4. The AuthenticationRequest is received by the identity provider. At this point, the identity provider verifies it is correct and safe.

Next, the identity providers checks if the user browser does have an active SSO session. In such a case, skip to step 6.

5. The identity providers ask for credentials to the user.

6. The user enters its credentials. At this time, the identity provider verifies the user name and password are correct, and creates a new SSO session.

7. The identity provider sends a SAML assertion to the service provider. This assertion is signed using its private key and optionally encrypted using the service provider public key. The SAML assertion contains some user attributes. The included attributes and its value can vary depending on the service provider that will receive it. 
As previously seen in the authentication request, the assertion is always sent through the user’s browser.

8. The service provider receives the SAML assertions, decrypts and verifies it, obtaining all the user attributes.

Single Log-out

The single log-out process follows the next UML diagram:



Description

1. The user requests to log out the application. At this point, the application (service provider) can give the user the chance to log out from any other application.

2. The service provider issues a global SAML logout request to the identity provider. The SAML logout request includes the user or session id. It is signed using its private key and optionally encrypted with the identity provider public key.

3. The identity provider sends a SOAP SAML logout request to any service provider with active sessions for this user. These logout requests are almost identical to the one sent from the service provider to the identity provider, but it is sent using SOAP rather than an HTTP URL.

4. After closing any active session, the user is informed about the logout progress, or optionally redirected to a farewell web page specified by the service provider.


The logout request must be signed, it is not mandatory to the login request.


SAML

SAML Example

Service Provider

image-1681222787894.png

OpenID-Connect

OpenID-Connect

OpenID-Connect

Introduction

OpenID is an open standard and decentralized authentication protocol.  It allows users to be authenticated by cooperating sites (known as relying parties, or RP) using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each.

It is identity layer on top of the OAuth 2.0 protocol. OpenID-Connect is based on most modern protols. It uses JSON tokens, signed and optionally encripted using JWT standard, and uses simple REST as its transport protocol.

Sometimes referred as OpenID, must not be confused with an older and deprecated standard named OpenID.

1024px-OpenID_logo_2.svg.png

https://openid.net/

https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)

OpenID-Connect

OpenID-Connect architecture

Introduction

OpenID is based on the well known protocol. It is easier to implement and deploy, as it does not require digital signature or  encryption. The drawback is that it is significantly less secure. For example, the single logout protocol is not finished yet.

Single Log-in

The usual log-in process follows the next UML diagram:

Description

1. User’s browser tries to get a web page from the service providers

2. . The service provider wants to authenticate the user identity. To get this, redirects the user to the identity provider, including the returning URL.

3.  The authorization request is received by the identity provider. At this point, the identity provider verifies it is issued by an authorized service provider.

Next, the identity providers checks if the user browser does have an active SSO session. In such a case, skip to step 6.

4. The identity providers ask for credentials to the user.

5.  The user enters its credentials. At this time, the identity provider verifies the user name and password are correct, and creates a new SSO session.

6.  The identity provider redirects the user to the service provider, sending an authorization code.

7. The service provider connects to the identity provider, using its client id and client secret, as well as the authorization code.

8. The identity provider verifies the authorization code and generates two tokens: the oAuth token and the OpenID token. The  Auth token is a bare token that can be used by the service provider to perform additional requests.

The Openid token contains some user attributes. The included attributes and its value can vary depending on the service  provider that will receive it. This token can be signed using JWT standard.

9. The service provider receives the both tokens, parsing the JSON document contained in the JWT OpenID token.

Single Log-out

One generic logout process diagram:

Description

1. The user requests to log out the application.

2. Logout in the Service Provider, for instance, delete cookies.

3. Redirect to the Identity Provider logout endpoint

4. Logout in the Identity Provider, for instance, delete cookies.

5. The Identity Provider can trigger logout from other Service Providers using Font-channel or Back-channel. 

6. The Identity Provider redirects to the Service Provider EndPoint

7. The Service Provider returns successfully logout

OpenID-Connect

OpenID-Connect example

Identity Provider

image-1661408366204.png

Service Provider

image-1661408426358.png

CAS

CAS

CAS (Central Authentication Service)

Introduction

The CAS protocol is a simple and powerful ticket-based protocol. It involves one or many clients and one server. Clients are embedded in CASified applications (called “CAS services”) whereas the CAS server is a standalone component.

The Cas protocol makes it possible to implement the SSO authentication method that allows users to access web applications with a single sign-on.

The specification versions recognized are 3.0.3 and 2.0

cas_max_logo_0.png

https://apereo.github.io/cas/6.5.x/protocol/CAS-Protocol.html

CAS

CAS architecture

Introduction

The CAS is a Single Sign On protocol for the web. This protocol allows users to access multiple applications by providing their credentials.

The response will be a JSON or XML 

Single Log-in

The single log-in is usually initiated by the application server. The typical UML use case is as follows:

image-1661327423181.png

Proxy web flow diagram

image-1661327695882.png

https://en.wikipedia.org/wiki/Central_Authentication_Service


CAS

CAS Example

Service Provider

image-1661408241083.png

Radius

Radius

Radius (Remote Authentication Dial-In User Service)

Introduction

The Radius protocol (Remote Authentication Dial-In User Service) is a networking protocol that authorizes and authenticates users who access a remote network.


https://es.wikipedia.org/wiki/RADIUS

Radius

Radius architecture

Introduction


image-1661408963698.png


Access Reject: The user is unconditionally denied access to all requested network resources. Reasons may include failure to provide proof of identification or an unknown or inactive user account.

Access Challenge: Requests additional information from the user such as a secondary password, PIN, token, or card. Access Challenge is also used in more complex authentication dialogs where a secure tunnel is established between the user machine and the Radius Server in a way that the access credentials are hidden from the NAS.

Access Accept: The user is granted access. Once the user is authenticated, the RADIUS server will often check that the user is authorized to use the network service requested. A given user may be allowed to use a company's wireless network, but not its VPN service, for example. Again, this information may be stored locally on the RADIUS server, or may be looked up in an external source such as LDAP or Active Directory.

https://en.wikipedia.org/wiki/RADIUS

Radius

Radius Example

Service Provider

image-1661409204083.png

TACACS+

Tacacs+

TACACS+

TACACS+ (The Terminal Access Controller Access-Control System Plus)

 TACACS+ is a security protocol that provides centralized validation of users who are attempting to gain access to a router or other devices.

TACACS+ is a protocol for AAA services:



https://www.rfc-editor.org/rfc/rfc8907.html

TACACS+

TACACS+ architecture


Introduction

TACACS+

TACACS+ Example

Service Provider

image-1681221680349.png

Information Systems

When a Tacacs Service Provider is created, Soffid creates an Information System

image-1681221732876.png

There are some roles defined for this Information System (0: anonymous, 1: user, ....15: root)

image-1681221803826.png

WS-Fed

WS-Federation

WS-Fed

WS-Fed

WS-Federation (Web Services Federation) is an Identity Federation specification

WS-Federation defines mechanisms for allowing different security realms to broker information on identities, identity attributes and authentication. WS-Federation focuses on federated identity and trusting authentication tokens across different realms, privileged password management is concerned with the security, control, and audit of high-risk account passwords within an IT environment

WS-Fed will only be used with Exchange and a few other applications.

https://en.wikipedia.org/wiki/WS-Federation

WS-Fed

WS-Fed Architecture

Introduction

WS-Federation (Web Services Federation) is an Identity Federation specification

Sign-On


http://docs.oasis-open.org/wsfed/federation/v1.2/cd/ws-federation-1.2-spec-cd-01.html

WS-Fed

WS-Fed Example

Steps

Attribute definition

First of all, will be mandatory to create two new attributes 

image-1695799061910.png

Bear in mind, that those attributes have to be retrieved from the appropriate system:

image-1695803778715.png

And those attributes have to be defined in the object metadata:

image-1695804665489.png

Attribute sharing policies

Define the proper attribute policy

image-1695801239762.png

Service Provider

image-1695801347498.png

Configure Exchange

Finally, you must configure the Exchange.

1.- Upload the SAML certificate to the certificate repository

2.- Search for the thumbprint of the certificate:

Set-Location Cert:\LocalMachine\Root; Get-ChildItem | Short-Object Subject

image-1695814095103.png

3.- From the Exchange Management Shell, run:

Set-OrganizationConfig -AdfsIssuer https://gbr.idp.demo.soffid.net/profile/wsfed `
   -AdfsAudienceUris "https://gbr.owa.demo.soffid.net/owa/","https://gbr.owa.demo.soffid.net/ecp/"  `
   -AdfsSignCertificateThumbprint "XXXXXXXXXXXXXXXX"
Set-OWAVirtualDirectory -Identity "OWA (Default Web Site)" -AdfsAuthentication $true   `
  -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false `
  -WindowsAuthentication $false
Set-ECPVirtualDirectory -Identity "ECP (Default Web Site)" -AdfsAuthentication $true   `
  -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false `
  -WindowsAuthentication $false
net stop was /y
net start  w3svc

The server must be up to date. Otherwise WS-Fed will reject the response

How to install Federation in Soffid?

Installation

Download

Please download the Soffid Federation add-on.

You could download it at the following link http://www.soffid.com/download/enterprise/ if you have a Soffid user with authorization, or in the following http://download.soffid.com/download/ by registering.

Upload

1. Once the Federation add-on is downloaded, please log in to IAM Console.

You need to be an administrator user of the Soffid console or a user with permission to upload addons.

2. In the Soffid console, please go to:

Main Menu > Administration > Configure Soffid > Global Settings > Plugins

3.  Then, click the add button (+) and pick the file and Soffild will upload the addon file.

4. Finally, when the addon is installed, it will be required to restart the Soffid Console and the Sync Server.

5. Once the Soffid console is restarted, you could check the plugin was uploaded properly on the plugins page:

Main Menu > Administration > Configure Soffid > Global Settings > Plugins

6. Now, you can set up the Federation.


Web SSO

Web SSO

⏰ Getting started

Introduction

To configure the Web SSO you must complete the next steps

1. Attribute definition: add the necessary attributes if they are not in the list.

2. Attribute sharing policies: define the proper attribute sharing policies to determine which attributes will be shared. The policies will apply to those IdPs that meet the conditions defined in the policy. You can define public policies that apply to all IdPs, or specific policies that only apply to certain IdPs.

3. Identity & Service providers: configure the identity and the service provider.

Soffid performs the validation in the following order

1. Login: first of all, it checks the login, if the access is correct then follow the next step

2. Policies: then, it checks the attribute sharing policies. Soffid checks all policies and applies the ones that meet the conditions.

3. Attributes: For policies that result in Yes or True, the attribute conditions will be evaluated. The attributes will be shared when the conditions are true.


Web SSO

Attribute definition

Description

The attribute definition page displays all the auto-generated user attributes. Those attributes will be the attributes to deliver from the identity providers to the service providers depending on the defined rules.

Soffid has a default implementation for common attributes like FullName or uid, but you can modify it by creating a custom script.

Screen overview

Custom attributes

Examples

Soffid IdP has a default implementation for common attributes like FullName or uid, but you can modify it by creating a custom script. You can use the custom script to define the value of an attribute.

Examples to define the value of an attribute.

Example 1

Return full name in upper case:

return fullName.toUpperCase();

Example 2

Send one value if an attribute is blank. Otherwise, its value:

return
    attributes{"company"} == null ||
    attributes{"company"}.isEmpty() ?
        "Soffid" :
        attributes{"company"}

Example 3

Use serverService to fech the OU attribute of the account owned by the user in the Active Directory (AD) system:

for (account: serverService.getUserAccounts(id, "ad")) {
    return account{"attributes"}{"ou"};
}
return null;

Actions

Attribute definition query

Add new

Allows you to add a new attribute definition in the system. You can choose that option on the hamburger menu or clicking the add button (+).

To add a new it is necessary to fill in the required fields.
Delete

Allows you to remove one or more Attribute definitions  by selecting one or more records and next clicking the button with the subtraction symbol (-).

To perform that action, Soffid will ask you for confirmation, you could confirm or cancel the operation.
Import

Allows you to upload a CSV file with the attribute definition to add or update attribute definition to Soffid.

First, you need to pick up a CSV file, that CSV has to contain a specific configuration. Then you need to check the content to be loaded, it is allowed to choose if you want or not to load a specific attribute. And finally, you need to select the mappings for each column of the CSV file to import the data correctly and to click the Import button.

Download CSV file

Allows you to download a CSV file with the basic information of all attribute definitions. 

Attribute definition detail

Delete

Allows you to save the data of a new Attribute definition or to update the data of a specific Attribute definition. To save the data it will be mandatory to fill in the required fields.

Save

Allows you to download a csv file with the basic information of the Attribute definition.


Web SSO

Attribute sharing policies

Description

After defining the attributes to publish, it’s required to write a policy that defines which attributes will be allowed to share with each service provider.

Soffid allows you to define security rules that apply to any attribute that should be delivered from identity providers to service providers.

Custom attributes

Condition

It is a boolean expression to be evaluated. The condition will be evaluatuated when the Allow value was yes. You can use the conditions to configure the conditions policy and to configure the shared attributes.

The boolean operator are the follow:

Examples

Examples to define conditions in an attribute sharing policy:

Example 1

Give the email address and the user ID to any trusted service provider. We define this as a public policy.

image-1651591008906.png

image-1652347213357.png

Example 2

Give some extra attributes, like full name and roles to any service provider belonging to soffid-demo entity group

image-1651732807889.png

image-1652347060000.png

Example 3

Rule that will be applied to the service provider named “test’ or any other service provider whose name starts with “soffid-”


image-1652347158677.png

image-1652347180776.png

Actions

Attribute sharing policies query

Add new

Allows you to add a new Attribute sharing policies in the system. You can choose that option on the hamburger menu or clicking the add button (+).

To add a new it is necessary to fill in the required fields.

Delete

Allows you to remove one or more Attribute sharing policies by selecting one or more records and next clicking the button with the subtraction symbol (-).

To perform that action, Soffid will ask you for confirmation, you could confirm or cancel the operation.
Import

Allows you to upload a CSV file with the ttribute sharing policies to add or update Attribute sharing policies to Soffid.

First, you need to pick up a CSV file, that CSV has to contain a specific configuration. Then you need to check the content to be loaded, it is allowed to choose if you want or not to load a specific attribute. And finally, you need to select the mappings for each column of the CSV file to import the data correctly and to click the Import button.

Download CSV file

Allows you to download a CSV file with the basic information of all Attribute sharing policies. 

Attribute sharing policies detail

Delete

Allows you to save the data of a new Attribute sharing policy or to update the data of a specific Attribute sharing policy. To save the data it will be mandatory to fill in the required fields.

Apply changes

Allows you to save the data of a new Metada object or to update the data of a specific Metadata object. To save the data it will be mandatory to fill in the required fields.

Undo

Allows you to quit without applying any changes made.


Web SSO

Identity & Service providers

Description

Soffid Identity Federation addon helps administrators to manage an Identity Federation. With Soffid you can manage the whole federation security configuration, increasing the security while reducing the federation management costs. Soffid can also act as a Service Provider, serving identities to any SAML capable application server.

The main supported standard is SAML. SAML allows to completely detach the identification process from web applications,  known as Service Providers. With SAML, identification is performed by specialized servers known as Identity Providers.  Additionaly, some other, less secure, but some times convenient protocols like OAuth (Open Authorization) and OpenID-Connect protocols are supported. Elder protocols like Openid (do not confuse with OpenID-Connect) are deprecated and no  longer supported.

You can visit the Introduction page to find more information about the federation members.

Federation members

1. Entity Group

2. Identity Provider

3. Service Provider

4. Virtual Identity Provider

Entity Group

Description

An entity group is just like a folder that allows you to manage different kinds of federation members. One of the most common ways to group federation members is by trust level.

When you create an entity group, the Identity Providers and the Service Providers records will be displayed. Then you could add identities and services selecting the proper record.

Screen overview

image-1652360950792.png

Standard attributes


Identity Provider

Description

An identity provider (abbreviated IdP or IDP) is a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network.

An Identity Provider is responsible for identifying users. Also, it is responsible for giving service providers information regarding the identified user.

Soffid allows you to configure different identity providers, you can choose the best option for you by selecting the IdP type:

To create an identity provider, it is advisable to install a dedicated sync server. It can be configured as a proxy sync server as it does not need direct access to the Soffid database. Instead, it will connect to the main sync server to get users and federation information.

For more information about how to configure a dedicated sync server, you can visit the Install Sync server page.

Standard attributes

The fields for each IdP type are detailed below:

Soffid IdP

Identification
Service Configuration

The Metadata is the information that any application needs to use the IdP. That is an XML file that contains the public encryption keys and the services provided

Leave it blank as Soffid IdP will fulfill it for you.

The metadata will be created when the network data and SAML Security data. Restarting the sync server will be necessary to fill in the Metadata.

Network
💻 Image

image-1709029065265.png

Server certificate management: there are two options for certificate management. You can visit the Server certificate management page for more information.

SAML Security
Session management
Authentication
Advanced Authentication
Profiles

A profile is a protocol or subset of protocols implemented by the Identity Provider. There are some accepted protocols, those allows a custom config dependent on the selected profile.

You can visit the Profiles chapter for more information about each one.

Look and feel

Soffid allows you to personalize your login page by adding some style elements, as well as header and footer elements.


External SAML IdP

Identification
Service Configuration

The Metadata is the information that any application need to use the IdP. That is an XML file that contains the public encryption keys and the services provided

Leave it blank as Soffid IdP will fulfill it for you.

Login Rules

OpenID-Connect

Service Configuration

 
{
    "authorization_endpoint": "https://server/oauth2/auth",
    "token_endpoint": "https://server/oauth2/token",
    "userinfo_endpoint": "https://server/oauth2/userinfo",
    "scopes_supported": [ "openid","email","profile"]
}

The Metadata is the information that any application need to use the IdP. That is an XML file that contains the public encryption keys and the services provided

Login rules

 
sn = attributes{"screen_name"};
i = sn.indexOf(" ");
if (i> 0) {
	user.firstName = sn.substring(0, i);
	user.lastName = sn.substring(i+1);
} else {
	user.firstName = "?";
  	user.lastName = sn;
}
return attributes{"name"};

Facebook

Identification
Service Configuration
Login rules

Google

Identification
Service Configuration
Login rules

Linkedin

Identification
Service Configuration
Login rules

(*) What is CAPTCHA --> https://support.google.com/a/answer/1217728?hl=en

(*) https://www.google.com/recaptcha/about/

Service Provider

Definition

The Service Providers are standard applications that rely on Identity Providers to let the users log in.

Join federation

To join the federation, the service provider management team must deliver its "Metadata". The service provider Metadata describes how the service providers behave:

Standard attributes

The standard attributes depend on the Service provider type.

SAML

To enable External SAML protocol you can visit the Authentication page. Also, on that page you could download the metadata XML file.

Identification
Service configuration

To publish the federation members' metadata, the main sync server exports the member's metadata at the path /SAML/metadata.xml. Thus, if your sync server is listening at soffid1.your.domain, you can get the whole federation metadata document from:

https://soffid1.your.domain:760/SAML/metadata.xml


After some seconds, up to five minutes, every federation member will notice any change.

Login rules
💻 Image

image-1718031321737.png

You can visit the Openid-connect to SAML interoperability page for more detailed information.

SAML API client

Identification
Service configuration

Leave it blank as Soffid IdP will fulfill it for you.

The metadata will be created when the network data and SAML Security data.

Login rules

You can visit the Openid-connect to SAML interoperability page for more detailed information.

Network
SAML Security
💻 Image

image-1718031233232.png

OpenID Connect

Identification
Login rules

You can visit the Openid-connect to SAML interoperability page for more detailed information.

OpenID authorization flow
💻 Image

image-1718031290130.png

OpenID Connect Dynamic Registration

Identification
Login rules
OpenID authorization flow
Registration token
💻 Image

image-1718031155504.png

Cas client

Identification
Login rules
CAS configuration
💻 Image

image-1718031131014.png

Radius client

Identification
Login rules
Radius configuration
💻 Image

image-1718031107168.png

TACACS+

Identification
Login rules
Tacacs+ configuration
💻 Image

image-1718031084991.png

https://www.rfc-editor.org/rfc/rfc8907.html

WS-Federation

Identification
Login rules
WS-Federation
💻 Image

 image-1718031500088.png


Virtual Identity Provider

Definition

A single identity provider usually offers different profiles or service levels to diffeferent service provider. To be able to define this behavior, any Identity Provider can be split into many virtual identity providers. Those identity providers will be served by the same actual identity provider, but they will have different profile configurations.

Standard attributes

Identification

Service configuration

Leave it blank as Soffid IdP will fulfill it for you.

SAML Security

Authentication

Advances authentication

Profiles

A profile is a protocol implemented by the Identity Provider. There are some accepted protocols, those allows a custom config dependent on the selected profile

You can visit the Profiles chapter for more information about each one.

Service Providers

It will be necessary to bind any service provider to the virtual identity provider. When no such bind exists for a service provider, the actual identity provider profile configuration applies. 

Actions

Federation Tree view

Add group

Allows you to create a new Entity group. You can choose that option by clicking on the "Add group" button, then Soffid will display a new window with the fields to fullfil.

To add a new Entity group it will be mandatory to fill in the required fields and save or apply changes..

Add identity provider

Allows you to add a new Identity Provider. You must click the "Add identity provider" button, under the proper Entity Group and "Identity Provider" label, then Soffid will display a new window with the data to fulfill for new Identity Provider.

To add a new Identity provider it will be mandatory to fill in the required fields and save or apply changes..

Add virtual identity provider

Allows you to add a Virtual Identity Provider. You must click the "Add virtual identity provider" button, under the proper Identity Provider, which has to be a Soffid IdP, then Soffid will display a new window with the data to fulfill for the new Virtual identity provider.

To add a new Virtual identity provider it will be mandatory to fill in the required fields and save or apply changes..

Entity goup 

List

Add new

You can add a new Entity groups by clicking on the add button (+). Then Soffid will display a new window and you need to fill in the required fields and save or apply changes.

Delete

Allows you to remove one or more Entity group by selecting one or more records and next clicking the button with the subtraction symbol (-).

To perform that action, Soffid will ask you for confirmation, you could confirm or cancel the operation.
Detail
Save

 

Allows you to save the data of a new Entity group or to update the data of a specific Entity group.

To save the data it will be mandatory to fill in the required fields

Apply changes

Allows you to save the data of a new Entity group or to update the data of a specific Entity group and quit.

To save the data it will be mandatory to fill in the required fields.

Delete

Allows you to delete the Entity group. To delete a host you can click on the hamburger icon and then click the delete button (trash icon).

Soffid will ask you for confirmation to perform that action, you could confirm or cancel the operation.

Undo

Allows you to quit without applying any changes made.

Identity Provider

List

Add new

You can add a new Identity provider by clicking on the add button (+). Then Soffid will display a new window and you need to fill in the required fields and save or apply changes.

Delete

Allows you to remove one or more Identity providers by selecting one or more records and next clicking the button with the subtraction symbol (-).

To perform that action, Soffid will ask you for confirmation, you could confirm or cancel the operation.
Detail
Save

 

Allows you to save the data of a new Identity provider or to update the data of a specific Identity provider.

To save the data it will be mandatory to fill in the required fields

Apply changes

Allows you to save the data of a new Identity provider or to update the data of a specific Identity provider and quit.

To save the data it will be mandatory to fill in the required fields.

Delete

Allows you to delete the Identity provider. To delete a host you can click on the hamburger icon and then click the delete button (trash icon).

Soffid will ask you for confirmation to perform that action, you could confirm or cancel the operation.

Undo

Allows you to quit without applying any changes made.

Service Provider

List

Add new

You can add a new Service provider by clicking on the add button (+). Then Soffid will display a new window and you need to fill in the required fields and save or apply changes.

Delete

Allows you to remove one or more Service providers by selecting one or more records and next clicking the button with the subtraction symbol (-).

To perform that action, Soffid will ask you for confirmation, you could confirm or cancel the operation.
Detail
Save

 

Allows you to save the data of a new Service provider or to update the data of a specific Service provider.

To save the data it will be mandatory to fill in the required fields

Apply changes

Allows you to save the data of a new Identity provider or to update the data of a specific Service provider and quit.

To save the data it will be mandatory to fill in the required fields.

Delete

Allows you to delete the Service provider. To delete a host you can click on the hamburger icon and then click the delete button (trash icon).

Soffid will ask you for confirmation to perform that action, you could confirm or cancel the operation.

Undo

Allows you to quit without applying any changes made.

Virtyal Identity Provider

List

Add new

You can add a new Virtual identity provider by clicking on the add button (+). Then Soffid will display a new window and you need to fill in the required fields and save or apply changes.

Delete

Allows you to remove one or more Virtual identity providers by selecting one or more records and next clicking the button with the subtraction symbol (-).

To perform that action, Soffid will ask you for confirmation, you could confirm or cancel the operation.
Detail
Save

 

Allows you to save the data of a new Virtual identity provider or to update the data of a specific Virtual identity provider.

To save the data it will be mandatory to fill in the required fields

Apply changes

Allows you to save the data of a new Virtual identity provider or to update the data of a specific Virtual identity provider and quit.

To save the data it will be mandatory to fill in the required fields.

Delete

Allows you to delete the Virtual identity provider. To delete a host you can click on the hamburger icon and then click the delete button (trash icon).

Soffid will ask you for confirmation to perform that action, you could confirm or cancel the operation.

Undo

Allows you to quit without applying any changes made.


https://en.wikipedia.org/wiki/Federated_identity

https://en.wikipedia.org/wiki/Identity_provider

https://en.wikipedia.org/wiki/Service_provider

Web SSO

Shared signals & events members

Federation members

Federation members

Entity Group

Description

An entity group is just like a folder that allows you to manage different kinds of federation members. One of the most common ways to group federation members is by trust level.

When you create an entity group, the Identity Providers and the Service Providers records will be displayed. Then you could add identities and services selecting the proper record.

Screen overview

image-1652360950792.png

Standard attributes


Federation members

Identity Provider

Description

An identity provider (abbreviated IdP or IDP) is a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network.

An Identity Provider is responsible for identifying users. Also, it is responsible for giving service providers information regarding the identified user.

Soffid allows you to configure different identity providers, you can choose the best option for you by selecting the IdP type:

To create an identity provider, it is advisable to install a dedicated sync server. It can be configured as a proxy sync server as it does not need direct access to the Soffid database. Instead, it will connect to the main sync server to get users and federation information.

For more information about how to configure a dedicated sync server, you can visit the Install Sync server page.

Standard attributes

The fields for each IdP type are detailed below:

Soffid IdP

Identification
Service Configuration

The Metadata is the information that any application needs to use the IdP. That is an XML file that contains the public encryption keys and the services provided

Leave it blank as Soffid IdP will fulfill it for you.

The metadata will be created when the network data and SAML Security data. Restarting the sync server will be necessary to fill in the Metadata.

Network
💻 Image

image-1709029065265.png

Server certificate management: there are two options for certificate management. You can visit the Server certificate management page for more information.

SAML Security
Session management
Authentication
Advanced Authentication
Profiles

A profile is a protocol or subset of protocols implemented by the Identity Provider. There are some accepted protocols, those allows a custom config dependent on the selected profile.

You can visit the Profiles chapter for more information about each one.

Look and feel

Soffid allows you to personalize your login page by adding some style elements, as well as header and footer elements.


External SAML IdP

Identification
Service Configuration

The Metadata is the information that any application need to use the IdP. That is an XML file that contains the public encryption keys and the services provided

Leave it blank as Soffid IdP will fulfill it for you.

Login Rules

OpenID-Connect

Service Configuration

 
{
    "authorization_endpoint": "https://server/oauth2/auth",
    "token_endpoint": "https://server/oauth2/token",
    "userinfo_endpoint": "https://server/oauth2/userinfo",
    "scopes_supported": [ "openid","email","profile"]
}

The Metadata is the information that any application need to use the IdP. That is an XML file that contains the public encryption keys and the services provided

Login rules

 
sn = attributes{"screen_name"};
i = sn.indexOf(" ");
if (i> 0) {
	user.firstName = sn.substring(0, i);
	user.lastName = sn.substring(i+1);
} else {
	user.firstName = "?";
  	user.lastName = sn;
}
return attributes{"name"};

Facebook

Identification
Service Configuration
Login rules

Google

Identification
Service Configuration
Login rules

Linkedin

Identification
Service Configuration
Login rules

(*) What is CAPTCHA --> https://support.google.com/a/answer/1217728?hl=en

(*) https://www.google.com/recaptcha/about/

Federation members

Service Provider

Definition

The Service Providers are standard applications that rely on Identity Providers to let the users log in.

Join federation

To join the federation, the service provider management team must deliver its "Metadata". The service provider Metadata describes how the service providers behave:

Standard attributes

The standard attributes depend on the Service provider type.

SAML

To enable External SAML protocol you can visit the Authentication page. Also, on that page you could download the metadata XML file.

Identification
Service configuration

To publish the federation members' metadata, the main sync server exports the member's metadata at the path /SAML/metadata.xml. Thus, if your sync server is listening at soffid1.your.domain, you can get the whole federation metadata document from:

https://soffid1.your.domain:760/SAML/metadata.xml


After some seconds, up to five minutes, every federation member will notice any change.

Login rules
💻 Image

image-1718031321737.png

You can visit the Openid-connect to SAML interoperability page for more detailed information.

SAML API client

Identification
Service configuration

Leave it blank as Soffid IdP will fulfill it for you.

The metadata will be created when the network data and SAML Security data.

Login rules

You can visit the Openid-connect to SAML interoperability page for more detailed information.

Network
SAML Security
💻 Image

image-1718031233232.png

OpenID Connect

Identification
Login rules

You can visit the Openid-connect to SAML interoperability page for more detailed information.

OpenID authorization flow
💻 Image

image-1718031290130.png

OpenID Connect Dynamic Registration

Identification
Login rules
OpenID authorization flow
Registration token
💻 Image

image-1718031155504.png

Cas client

Identification
Login rules
CAS configuration
💻 Image

image-1718031131014.png

Radius client

Identification
Login rules
Radius configuration
💻 Image

image-1718031107168.png

TACACS+

Identification
Login rules
Tacacs+ configuration
💻 Image

image-1718031084991.png

https://www.rfc-editor.org/rfc/rfc8907.html

WS-Federation

Identification
Login rules
WS-Federation
💻 Image

 image-1718031500088.png


Federation members

Virtual Identity Provider

Definition

A single identity provider usually offers different profiles or service levels to diffeferent service provider. To be able to define this behavior, any Identity Provider can be split into many virtual identity providers. Those identity providers will be served by the same actual identity provider, but they will have different profile configurations.

Standard attributes

Identification

Service configuration

Leave it blank as Soffid IdP will fulfill it for you.

SAML Security

Authentication

Advances authentication

Profiles

A profile is a protocol implemented by the Identity Provider. There are some accepted protocols, those allows a custom config dependent on the selected profile

You can visit the Profiles chapter for more information about each one.

Service Providers

It will be necessary to bind any service provider to the virtual identity provider. When no such bind exists for a service provider, the actual identity provider profile configuration applies. 

Profiles

Profiles

Profiles

Description

A profile is a protocol or subset of protocols implemented by the Identity Provider. There are some accepted protocols, those allows a custom config dependent on the selected profile.

The accepted protocols are the following:

1. OpenIDProfile

2. SAML1ArtifactResolutionProfile

3. SAML1AttributeQueryProfile

4. SAML2ArtifactResolutionProfile

5. SAML2AttributeQueryProfile

6. SAML2ECPProfile

7. SAML2SSOProfile

8. CAS

9. Radius

10. Tacacs+

11. Ws-Federation

12. Shared signals & events

13. Esso

Screen overview

image.png

When an identity provider is created, by default, all the profiles appear disabled (the profile is displayed strikethrough). It will be necessary to config one by one depending on your company needs. To config a profile you must click on the proper profile, and Soffid will display a new window to config it.

Actions

Open profile

If you click on a row of the profile list, Soffid will display a modal window with the data and configuration of the profile selected.


Profiles

OpenIDProfile

Definition

The Identity Provider will serve the OpenID-Connect protocol. It is possible to accept the default endpoints or modify them.

You can check the server features visiting https://<YOUR-IdP>/.well-known/openid-configuration. That JSON gives you information about the oAuth authentication types allowed, the key URL, the soported authentication methods and the info about the endpoints defined.

You can download an example openid-configuration.json

Screen overview

Standard attributes


Profiles

SAML1ArtifactResolutionProfile

Definition

Based on SAML version 1 standard. This profile is used when the Service Provider wants to resolve or check a received assertion.

Screen overview

image-1638533916859.png

Standard attributes



Profiles

SAML1AttributeQueryProfile

Definition

Based on SAML version 1 standard. This profile is used when the SSOProfile does not include attributes statements in the assertion. This profile allows to the applications request user data.

When you are configuring the profile, you could define what data will be encrypted and signed.

Screen overview

image-1638533961155.png

Standard attributes

Assertion Lifetime examples:

https://en.wikipedia.org/wiki/ISO_8601 

http://saml.xml.org/saml-specifications

Profiles

SAML2ArtifactResolutionProfile

Definition

Based on SAML version 1 standard. This profile is used when the Service Provider wants to resolve or check a received assertion. The profile configuration settings are quite similar to those present in SAML2SSOProfile.

When you are configuring the profile, you could define what data will be encrypted and signed.

Screen overview

image-1638534011855.png

Standard attributes


Profiles

SAML2AttributeQueryProfile

Definition

Based on SAML version 1 standard. This profile is used when the SSOProfile does not include attributes statements in the assertion. This profile allows to the applications request user data.

When you are configuring the profile, you could define what data will be encrypted and signed.

Screen overview

image-1638534055413.png

Standard attributes


Profiles

SAML2ECPProfile

Definition

The Enhanced Client Profile is used when the Service Provider is not a web application. Nowadays, it is rarely used, as most mobile applications have shifted to OAuth or OpenIDConnect.

When you are configuring the profile, you could define what data will be encrypted and signed.

Screen overview

image-1638534117678.png

Standard attributes


Profiles

SAML2SSOProfile

Definition

This is the most commonly used SAML profile. It allows the IdP to identify users and to give such information to Service Providers. This profile is used to log in.

When you are configuring the profile, you could define what data will be encrypted and signed.

Screen overview

image-1638534204054.png

Standard attributes


Profiles

CAS

Definition

Cas protocol is rarely used.

Screen overview

image-1661330455520.png

Standard attributes

Profiles

Radius

Definition

Networking protocol that authorizes and authenticates users who access a remote network.

Screen overview

image-1661330603198.png

Standard attributes

Profiles

ESSO

Definition

Here is an explanation about how to configure the ESSO profile by using Soffid as Identity Provider.

Please note that the profile parameters will be automatically updated on the PCs.

Screen overview

image.png

Standard attributes

Configuration

Once you have configured the Esso profile you must add an Adaptive authentication rule.

For more information, visit the Condition for Adaptive authentication page.

image.png

Condition for Adaptive authentication

Introduction

Adaptive authentication is designed to improve the security of online accounts by adding an additional layer of protection against unauthorized access.

When the authentication is being defined, Soffid allows you to add some adaptive authentications in addition to the Authentication methods. Those adaptive authentications will be evaluated, and when the result of the condition will be true, the rule will be enabled.

Screen overview

image-1691748261720.png

Standard attributes

Description

Description to identify the rule

Condition

Allows you to write a script validation, with the result true or false. To develop the script you can use some vars defined to that:

There are some available vars to create the condition:

Authentication methods available: 

Matrix

To define the authentication methods that will be required to successfully authenticate the user. Each row indicates the first authentication method, and each column indicates the second factor to use.

Actions

Apply changes

Allows you to save the data of a new adaptive authentication or to update the data of the previously created adaptive authentucation.

Add

Allows you to add a new adaptive authentication. When you click the add button (+) Soffid will display new fields to fill in. For each adaptive authentication you must fulfill the description, the condition to evaluate and the matrix which will be enable when the condition will be true.

Then you must click on the "Apply changes" button to save the data.

Delete

Allows you to remove one by one the adaptive authentication defined. You must click on the trash icon the account of the proper rule. Then you must click the "Apply changes" button to save the data.

Up

Allows you to reorder (up) the defined adaptive authentication.

Down

Allows you to reorder (down) the defined adaptive authentication.

Examples

Rule 1
failuresRatio > 0.8
Rule 2
(daysSinceLastLogon > 10) && (ipAddress.startsWith("192.168.")
Rule 3
((dayOfWeek == 7) || (dayOfWeek == 1)) &&  (user!=null && "<USER_NAME>".equals(user.userName))
Rule 4
"ES".equals(sourceCountry) || ipAddress.startsWith("192.168.")
Rule 5
isEsso
Rule 6
if (daysSinceLastLogonByMethod["PO"] == null || daysSinceLastLogonByMethod["PO"] > 30) 
   return true;
Rule 7
"YOUR_SERVICE_PROVIDER".equals(serviceProvider)
Rule 8
"P".equals(currentAuthenticationMethod)

How to deploy the identity & service provider

How to deploy the identity & service provider

How to deploy the identity & service provider

Step-by-step

1. To deploy the identity provider is advisable to install a dedicated sync server. It can be configured as a proxy sync server as it does not need direct access to Soffid database. Instead, it will connect to main sync servers to get users and federation information. Also, you can deploy the identity provider in your existing sync.

To install a proxy sync server follow the instructions at the Install sync server page. 

2. If the installation is in a dedicated Sync server:

2.1. You need open the Sofid Console and approve the Task to accept the new Sync server.

2.1. You need tune the Sync server memory usage.

Main Menu > Administration > Configure Soffid > Integration engine > Synchronization servers

3. Once the Sync server is registered, if you want to create a Soffid IdP you must create a new Identity Provider Agent.

Main Menu > Administration > Configure Soffid > Integration engine > Agents

Your identity provider agent should look like this one:

4. Upload the Federation addon to the Soffid Console:

To upload the addon follow the instructions at the How to install Federation in Soffid page.

5. Once you are connected to the Soffid console, you can start creating an Entity Group.

5.1. First of all, open the  Identity & Service providers page

Main Menu > Administration > Configure Soffid > Web SSO > Identity & Service providers

5.2. Then, click the "Add group" button and Soffid will display a new window to fill in the Entity group attributes.

5.3. Once you fill in the fields, you need to save (disk button) or apply changes (Apply changes button) to save the data.

When the Entity Group is created, inside there will be two options, one to create the Identity Providers and other to create the Service Providers.

5.3.1. Clicking on the Identity Providers record a identity providers list will be displayed and it will be able to create new identity providers. To create a new Identity Provider continue on step 5rd.

5.3.2. Clicking on the Service Providers record a service provider list will be displayed and it will be able to create new service providers. To create a new Service Provider continue on step 6th.

6. New Identity Provider:

6.1. To create a new Identity Provider you can click on the "Add identity provider" button on the tree view, or click the add button (+) on the Identity Provider list. Then Soffid will display a new window.

6.2. At the new window you must select the IdP type you want to create and fill in the required fields. The fields to full fill depend on the IdP type selected.

6.2.1. When creating a Soffid identity provider, it will be mandatory to create an agent. The agent will have to be a Soffid Identity Provider agent. On the connector parameters you must define a unique Public ID which will be used on the Identity Provider configuration.

6.3. Once you fill in all the data, you need to enable the proper profiles by clicking on the profile list and configuring them.

6.4. Finally, you need to save (disk button) or apply changes (Apply changes button) to save the data.

Note that in some cases it will be necessary to restart the synchronization server, so Soffid will generate the additional metadata or certificate data needed.

Note that you may have to open the standard port.

Soffid Identity Provider Screenshot

image-1691748396068.png


image-1691748424764.png


You could check your Identity Provider
https://<YOUR_SYNCSERVER_HOSTNAME>:1443/protected

For instance: https://iam-sync-idp.soffidnet:1443/protected

You could view your IdP metadata
https://<YOUR_SYNCSERVER_HOSTNAME>:1443/SAML/metadata.xml

For instance: https://iam-sync-idp.soffidnet:1443/SAML/metadata.xml

In addition, the complete metadata of soffid
https://<YOUR_SYNCSERVER_PRINCIPAL>:1760/SAML/metadata.xml

For instance: https://iam-sync.soffidnet:1760/SAML/metadata.xml

7. New Service Provider:

7.1. To create a new Service Provider you can click on the "Add service provider" button on the tree view, or click the add button (+) on the Service Provider list. Then Soffid will display a new window.

7.2. At the new window you must select the Service provider type you want to create and fill in the required fields. The fields to full fill depend on the IdP type.

7.3. One you fill in all the data, you need to save (disk button) or apply changes (Apply changes button) to save the data.

SAML Service Provider Screenshot

image-1652361192558.png

OpenID Connect Service Provider Screenshot

image-1652361115515.png


8. Enable, when it will be necessary, the External SAML identity provider. To do that you need to access to the Authentication page:

Main Menu > Administration > Configure Soffid > Security settings > Authentication

image-1643294485047.png

You can visit the Authentication page for more information.


How to deploy the identity & service provider

Change Password URL


There is a service point to allow users change their passwords. Simply redirect the user to:

https://<YOUR_SYNCSERVER_HOSTNAME>:1443/protected/passwordChange

For instance: https://iam-sync-idp.soffidnet:1443/protected/passwordChange

💻 Image

image-1714486394997.png

The user will be required to enter identify itself and enter a new password. Optionally, you can enter a web page to return after password change is complete:

https://servername:port/protected/changePassword?return=URL


How to deploy the identity & service provider

How to perform unsolicited login


Soffid Identity Provider supports unsolicited login (Idp initiated login) profile. In order to enable it, you must be sure that federation metadata for the target service provider allows it. It is configured using the AuthnRequestsSigned attribute of the SPSSODescriptor tag:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID=....." entityID="...Service Provider Public ID....">
  <md:SPSSODescriptor AuthnRequestsSigned="0" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">



Once it is enabled, you can access to:

https://IdentityProvider:port/profile/SAML2/Unsolicited/SSO?providerId=<ServiceProviderPublicID>

Now, you will be requested to show your credentials. If they are valid, you will be redirected to the service provider initial page.


Another way to achieve the same functionality when the service provider is Shibboleth, is to send the request directly to the service provider. This approach has an additional advantage, as you can specify which URL must be served by the service provider.

https://ServiceProvider:port/Shibboleth.sso/Login?target=TargetURL


How to enable Kerberos authentication

Step-by-step

To enable the kerberos authentication method, the identity provider must have a keytab file that enables it to authenticate users. The steps to get it are described below:

1. First of all, you need to create a net user. You can use the old-fashioned but still useful net user command:

NET USER SoffidIdP <NewPassword> /ADD /DOMAIN

2. The second step will be to create a service name and generate a keytab file.

KTPASS /out krb5.keytab /princ http/<YourIdp.Host.Name>@<Your.Ad.Domain> /mapuser SoffidIdp /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass <NewPassword> /target <Your.AD.Domain>

Mind that the browser expects the server name in the URL bar matches the principal name you have just created.

3. Finally, you need to add the keytab file to the identity provider configuration.

3.1. Open the  Identity & Service providers page

Main Menu > Administration > Configure Soffid > Web SSO > Identity & Service providers

3.2. Click on the Identity Provider you are configuring. Then Soffid will display the Identity Provider detail.

3.3. On the Authentication section, on the Kerberos domain list, you can click on the add button (+) to pick up the keytab file.

3.4. Pick up the keytab file and Soffid will load automatically into the console.

Mind that the active directory agent for this domain must be successfully connected, as it is needed to translate the kerberos identity to a user name.


Connecting Service Providers

Connecting Service Providers

Connecting an OpenID Connect service

Introduction

There are three basic OpenID flows, depending whether the service name must be authenticated using its client secret or not:

OpenID flow


Implicit flow

Client credentials flow

Password authentication flow

Register an OpenId Connect Service Provider

1. To register an OpenId Connect service provider, open the federation page:

Main Menu > Administration > Configuration > Web SSO > Identity & Service providers

2. Then, select an Entity Group and the branch Service Providers and click on the Add Service Provider button.

image-1689235669464.png

3. Soffid will display the following window:

image-1689236053673.png

For more information about the attributes, you can visit the OpenID Connect detailed info.

4. Finally, you must apply changes.

 

Examples

1. Authorization code flow

The client application creates a random String, named nonce, and sends to the user the following URL

Request

https://youridentityprovider:2443/authorization?

redirect_uri=https://<serviceprovider>/response&

client_id=MYCLIENT&

nonce=12345679801234567890&

scope=openid+test+other&

response_type=code

Then, the user will be asked for a username and password, or any other means of authentication. After authenticating the user, the browser will be redirected to the URL configured in the service provider page, adding a one-time authorization code.

https://<serviceprovider>/response/?
code=XXXXXXXXXXXXXXX&
nonce=12345679801234567980

Once the service provider has received the one-time authorization code, it can connect to the identity provider to retrieve the oAuth token, as well as the OpenID token.

Request

POST https://youridentityprovider:2443/token


HEADERS

Accept: application/json

Authorization: Basic dGVzdDp0ZXN0

Content-Type: application/x-www-form-urlencoded


BODY PARAMS

grant_type=authorization_code&

code=XXXXXXXXXXXX
Parameters

Response

{

    "access_token":"8bDP2P...",

    "refresh_token":"gjLmSW...",

    "id_token":"eyJra.eyJ.LQ_XtHKr.RY3A4...",

    "token_type":"Bearer",

    "expires_in":11998

}

Before the number of seconds specified om expires_in are elapsed, the token can be renewed by invoking again the token endpoint changing the grant_type:

Request

POST https://youridentityprovider:2443/token


HEADERS

Accept: application/json
Authorization: Basic dGVzdDp0ZXN0
Content-Type: application/x-www-form-urlencoded


BODY PARAMS

grant_type=refresh_token&

refresh_token=gjLmSW...
Parameters

Response

{

    "access_token":"8bDP2P...",

    "refresh_token":"gjLmSW...",

    "id_token":"eyJra.eyJ.LQ_XtHKr.RY3A4...",

    "token_type":"Bearer",

    "expires_in":11998

}

2. User’s password + client credentials flow

The application asks the user for the user name and password. Then, it connects to the token endpoint to get an access token:

Request

POST https://youridentityprovider:2443/token


HEADERS

Accept: application/json
Authorization: Basic dGVzdDp0ZXN0
Content-Type: application/x-www-form-urlencoded


BODY PARAMS

grant_type=password&
username=USER&
password=PASSWORD&XXXXXXXXXXXX
Parameters

Response

{
    "access_token":"8bDP2P...",
    "refresh_token":"gjLmSW...",
    "id_token":"eyJra.eyJ.LQ_XtHKr.RY3A4...",
    "token_type":"Bearer",
    "expires_in":11998
}

Before the number of seconds specified in expires_in are elapsed, the token can be renewed by invoking again the token endpoint:

Request

POST https://youridentityprovider:2443/token


HEADERS

Accept: application/json
Authorization: Basic dGVzdDp0ZXN0
Content-Type: application/x-www-form-urlencoded


BODY PARAMS

grant_type=refresh_token&

refresh_token=gjLmSW...
Parameters

Response

{
    "access_token":"8bDP2P...",
    "refresh_token":"gjLmSW...",
    "id_token":"eyJra.eyJ.LQ_XtHKr.RY3A4...",
    "token_type":"Bearer",
    "expires_in":11998
}

3. Closing the session

The application wants to revoke the token and session cookie:

Request

POST https://youridentityprovider:2443/revoke


HEADERS

Accept: application/json
Content-type: application/x-www-form-urlencoded
Authorization: Basic dGVzdDp0ZXN0


BODY PARAMS

token_type_hint=token=access_token&

token=8bDP2P...
Parameters

4. Getting user attributes

All the user attributes can be extracted from the OpenID token. Anyway, it is possible to get them in a more readable format user the user-info endpoint.

Request

GET https://youridentityprovider:2443/userinfo


HEADERS

Accept: application/json
Authorization: Bearer dGVzdDp0ZXN0
Parameters

Response

{

    "sub": "admin",

    "surname": "Admin",

    "given_name": "Admin",

    "member_of": [

        "TestRole2@soffid",

       "TestRole@soffid"

    ]

}

5. Getting a session cookie for the user

Sometimes, a mobile application has authenticated the user using the username & password grant, but wants to share this authenticated session with the underlying web browser. For such a case, the application can request a session cookie with this request:

Request

GET https://youridentityprovider:2443/session_cookie


HEADERS

Accept: application/json
Authorization: Bearer dGVzdDp0ZXN0
Parameters

Response

{

"cookie_domain": "cookied",
"user": "pgarcia",
"cookie_value": "5458083_bT2CZlaa6psl/q3ue6NObxX8Q7duQKj0hAuUJIouT5Y=",
"cookie_name": "cookien"

}

Please note that it is mandatory to fill in the name of the cookie in the identity provider, at the session management section


Connecting Service Providers

Connecting a SAML service

Introduction

To connect a SAML service provider, the service provider must offer you its SAML metadata. The SAML metadata contains information about its public id, the services that implement and the service endpoints.

Register a SAML service provider

1. Open the Identity & Service Provider page.

Main Menu > Administration > Configure Soffid > Web SSO > Identity & Service providers

2. To add a new service provider, click on the Add Service Provider button.

Be in mind that you can configure more than one Entity Group and you could add new service providers in each one.

3. Then you must fill in the required fields. Also, you need to provide the identity provider metadata. You can either copy it from the Soffid federation page or instruct the service provider to download the federation metadata by itself.

image-1689237747516.png

For more information about the attributes, you can visit the SAML detailed info.

4. To publish the federation members metadata, the main sync server exports the members metadata at the path /SAML/metadata.xml. Thus, if your sync server is listening at soffid1.your.domain, you can get the whole federation metadata document from https://soffid1.your.domain:760/SAML/metadata.xml.

5. After some seconds, up to five minutes, every federation member will notice any change.



Connecting Service Providers

Connecting Soffid console

Introduction

Soffid console has a built-in SAML client, so it can act as a service provider in the Soffid federation. It is interesting to use this configuration, as it allows you to enforce the use of two factors authentication to log into the Soffid console.

Register Soffid as a service provider

1. Enable the SAML protocol in the Soffid console:

1.1. Open the Authentication page:

Main Menu > Administration > Configure Soffid > Security settings > Authentication

1.2. You must enable the External XAML identity provider.

1.3. Then you must fill in the fields:

image-1689256229585.png


In that case, you must obtain the public certificate from the sync server and store in your Java trusted certs repository. To do that, use the keytool command. The trusted certs repository is located at <JAVA_HOME>/lib/security/cacerts

The command should look like the next one. When prompted for a password type in "changeit"

root@myserver:~$ /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/keytool
-import -file /tmp/RootCA -trustcacerts -alias syncserver
-keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts

2. Download Soffid console metadata: 

2.1. Open the Authentication page:

Main Menu > Administration > Configure Soffid > Security settings > Authentication

2.1. Click the Download metadata button and save the file.

image-1689329490746.png

This XML file is the metadata descriptor for the console, including a self-signed certificate generated to sign SAML requests.

The XML file will be like the next one:

3. Register Soffid Metadata in the third-party Identity Provider. 

4. You can use the Wizard to Add Applications

image-1689334608813.png

For more information, visit the Add Applications page.

5. Test it

5.1. Next time you log into the Soffid console, a new button will appear for External (XAML) login

image-1640009166065.png

5.2. Click on the External (SAML) login button, and the user will be forwarded to the identity provider.




Connecting Service Providers

Connecting your custom applications

Introduction

SAML 2.0 is a complex and not easy to implement standard. There are some libraries that can help somewhat, but a correct implementation needs a deep knowledge of SAML protocol, and is always hard to test and debug.

To make it easier, Soffid provides some JSON rest web services, that can help any application to correctly implement the SAML service provider part of the protocol.

Data flow

The following diagram, shows the resulting data flow between the end user, your application, the identity provider and Soffid web services:


Data flow steps

1. The end-user requests access to a protected page

2. The custom application can check the user identity looking up a session variable. By the time being, the user is not authenticated.

3. The custom application issues a JSON request to Soffid web service. In turn, Soffid web service builds, signs and maybe encrypts a SAML request

4. Then custom application taks the JSON request and builds an HTTP Redirect response with the received data.

5. The identity provider identifies the user as usual.

6. The custom application receives the SAML response. At this point, the application packs and forwards the received data to Soffid Web Service.

7. Soffid Web Service decrypts and checks SAML response integrity and correctnes, and returns a JSON document specifying the success or failure status, and the underlying identity attributes. If needed, Soffid web service can provision a new identity in target systems on the fly.

8. The custom application gets the identity data, stores it in a session variable and provides the protected resource to the end user.


In order to get it, will be necessary: 

  1. Declare the custom application as an internal service provider in the federation page.
  2. Create a Soffid application account for the custom application.
  3. Implement the protection filters.
  4. Implement the endpoint where the SAML response must be sent.

Example

1. Creating an internal service provider

You can create an internal service provider as a SAML service provider.

2. SAML Request generator

After deploying Soffid SAML addon, a web service to generate SAML request will be automatically deployed. This web service requires an account with the federation:serviceProvider authorization.

The endpoint will be locate in Soffid Console:

http://your.soffid.console:8080/webservice/federation/rest/generate-saml-request

Method:

POST

Headers to include in the request:

Accept = “application/json”
Content-Type = “application/json”

Request: Send a JSON decument with following fields:

user → suggested user to authenticate (optional)
identityProvider → identity provider public ID. Must match the public ID of any
identity provider registered in Soffid federation.
serviceProviderName → service provider which requests the user
authentication. Must match the public ID of an internal service provider
sessionSeconds → max time for the user session inactivity

Response:

method → Method to use: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
instructs the application to build a HTML Form that automatically submits the
following parameters. Value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
instructs the application to perform a redirect (Location HTTP header) with the
URL and parameters specified
parameters → every parameter included must be submited to the identity
provider. Usually, these two will be present:
RelayState → identifier of the ticket of the SAML request
SAMLRequest → encoded SAML request
url → identity provider endpoint.

Request sample:

{

    "user" : "myuser@soffid.poc",
    "identityProvider" : "my-service-provider",
    "serviceProviderName" : "https://idp.soffid.com",
    "sessionSeconds" : "3600"

}

Response sample:

{
    "method": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect",
    "parameters": {
        "RelayState":
              "_457cab260c4948ef4c6d35a67cac000d3348d1ec48f53215",
         SAMLRequest":
             “PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ..."
    },
   "url": "https://idp.soffid.com/SAML/Redirect"
}

3.

In turn, your application will issue the following location header to the browser

Location: https://idp.soffid.com/SAML/Redirect?RelayState=_457cab260c4948ef4c6d35a67cac000d3348d1ec48f53215&SAMLRequest=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ...

Should the method be urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, your application should build an HTML similar the following one:

<form action="https://idp.soffid.com/SAML/Redirect">
       <input   type="hidden"    name="RelayState"  value="457cab260c4948ef4c6d35a67cac000d3348d1ec48f53215" />
      <input   type="hidden"   name="SAMLRequest" value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ....."
/>
</form>
<script>
      document.form[0].submit();
</script>

4. SAML Response endpoints

Your application must implement the SAML response endpoint. This endpoint must accept the POST method and forward each received parameter to Soffid's parse-saml-response. Mind that your endpoint must accept application/x-www-form-urlencoded parametern while Soffid service accepts application/json.

Soffid endpoint will be located in Soffid Console:

http://your.soffid.console:8080/webservice/federation/rest/generate-saml-request

Method:

POST

Headers:

Accept = “application/json”
Content-Type = “application/json”

Authentication:

Use your application account to login using basic authentication schema. In multitenant environments, the user name will have the forma TENANT_NAME\ACCOUNT_NAME

Request: send a JSON document with following fields

autoProvision → [false|true] Set to true if you want Soffid to automatically enroll
unknown identities. This is not normally needed if you are using Soffid IdP, but it's
useful when using third party IdPs.
response: JSON object with any parameter received in post method.
RelayState → identifier of the ticket of the SAML response
SAMLResponse → encoded SAML response
protocol → use always “urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
serviceProviderName → service provider which requests the user authentication

Response:

authentication → [yes|no]
failureMessage → if authentication=”no”, a message with the error cause.
principalName → account name, as sent by the IdP
user → Soffid identity with standard attributes
attributes → Soffid identity custom attributes
sessionId → session identifier

Example data received by your endpoint

POST /saml-receiver
Host: my-service-provider
Content-Type: application/x-www-form-urlencoded
RelayState=_523866242f943b4c63234dc8942ffc2f08cea03aa129a4e2&SAMLResponse=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ.…
Example request

{
    "autoProvision" : false,
    "response" : {
        "RelayState":
            "_523866242f943b4c63234dc8942ffc2f08cea03aa129a4e2",
        "SAMLResponse":
            "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ...."
    },
    "protocol" : "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
    "serviceProviderName" : "my-service-provider"
}
Example response

{
    "authentication": "yes",
    "principalName": "your-name@somedomain.com",
    "user": {
        "id": 123456,
        "userName": "your-id",
        "firstName": "Your",
        "lastName": "Name",
        "primaryGroup": "enterprise",
        "active": true,
        "shortName": "your-name",
        "mailDomain": "somedomain.com"
    },
    "attributes": {
        "employeeId": "AS14567"
    },
    "sessionId": "ABCTASHO54684A"
}


Connecting Service Providers

Openid-connect to SAML interoperability

Introduction

OpenID-Connect has a clear design suitable for both frontend and backend.

SAML has a clear design for the frontend, but the backend usage is harder as the security in SAML cannot be placed at transport layer. Instead, in must be placed at document level. Additionally, it requires intensive use of cryptographic algorithms for signature and encryption.

That’s why some applications put a SAML frontend protection for both the frontend and relay on the session cookies generated by the fronted for backend access.

The problem arises when one service provider needs to invoke some services from a SAML enabled application that does not support or implement WS-Security.

To solve it, Soffid Identity Provider provides a service to get the session cookies required to access to a SAML application.

Data flow

The rest service /userinfo/impersonate?url=…. will do the job, and will return the cookies to use to act upon the target application impersonating the current user.



Request

POST https://<YOUR_SERVER>:2443/userinfo/impersonate?url=http://targetapplication/
Accept: application/json
Content-type: application/x-www-form-urlencoded
Authorization: Basic dGVzdDp0ZXN0

[
     {
         "path":"/",
         "domain":"samltest.id",
         "name":"_shibsession_64656661756c7468747470733a2f2f73616d6c746573742e69642f73616d6c2f7370",
         "value":"_fa49874951dd05c18a0f68642c0736e9"
     },
    {
        "path":"/",
        "domain":"samltest.id",
        "name":"_opensaml_req_ss%3Amem%3A88b0af3e1ff47c911257490bc1a5749dfda1670948a563cec2fdf9e8a799f2c4",
        "value":""

    }
]
Parameters

Response

The response contains the list of cookies to send to the target application.

[
     {
         "path":"/",
         "domain":"samltest.id",
         "name":"_shibsession_64656661756c7468747470733a2f2f73616d6c746573742e69642f73616d6c2f7370",
         "value":"_fa49874951dd05c18a0f68642c0736e9"
     },
    {
        "path":"/",
        "domain":"samltest.id",
        "name":"_opensaml_req_ss%3Amem%3A88b0af3e1ff47c911257490bc1a5749dfda1670948a563cec2fdf9e8a799f2c4",
        "value":""

    }
]

Request

Once the application has got the list of cookies, it can invoke the target application URL

POST https://targetapplication/api/service1
Accept: application/json
Content-type: application/json
Cookie: cookie1=value1


As security measures, the impersonation profile must be enabled, and the source application must be entitled to use it against the target application



Connecting Service Providers

Openid-connect Dynamic Register

Introduction

Openid-connect allows a service provider registers dynamically other service providers.

Dynamic Register

To dynamically register a client, acquire an initial access token, and then register the new application by using the registration API. You can get the access token from Soffid.

Register Server

Request
POST https://<YOUR_SERVER>:2443/register

Authorization

Header

JSON

{
    "application_type": "web",
    "redirect_uris":
        ["https://client.example.org/callback",
         "https://client.example.org/callback2"],
    "client_name": "My Example 7",
    "logo_uri": "https://client.example.org/logo.png",
    "subject_type": "pairwise",
    "token_endpoint_auth_method": "client_secret_basic",
    "jwks_uri": "https://client.example.org/my_public_keys.jwks",
    "userinfo_encrypted_response_alg": "RSA1_5",
    "userinfo_encrypted_response_enc": "A128CBC-HS256",
    "contacts": ["ve7jtb@example.org", "mary@example.org"],
    "request_uris":
        ["https://client.example.org/rf.txt#qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}
Response 200 OK
{
    "client_secret_expires_at": 0,
    "registration_client_uri": "https://iam-sync-tenantidp.soffidnet:2443/register?client_id=DR_7",
    "client_secret": "wBeH8G6hT2GRwr7jJ6HfX2lMJDGdwGi9M49SKF2MjHRGOtwZ",
    "redirect_uris": [
        "https://client.example.org/callback",
        "https://client.example.org/callback2"
    ],
    "registration_access_token": "NjYxODg1Ng.AFa8jQbltq+bocWQpT3okPvHXHrTM+HqXQC26Kz5mfAWfXWG",
    "client_name": "My Example 7",
    "client_id": "DR_7"
}

Client read request

Request
GET https://<YOUR_SERVER>:2443/register?client_id=DR_7

Authorization

Header

Params

Response
{
    "client_secret_expires_at": 0,
    "registration_client_uri": "https://iam-sync-tenantidp.soffidnet:2443/register?client_id=DR_7",
    "redirect_uris": [
        "https://client.example.org/callback",
        "https://client.example.org/callback2"
    ],
    "client_name": "My Example 7",
    "client_id": "DR_7"
}


Connecting Service Providers

Connecting CAS client

Introduction

The CAS protocol is a simple and powerful ticket-based protocol. It involves one or many clients and one server. Clients are embedded in CASified applications (called “CAS services”) whereas the CAS server is a standalone component.

Register CAS client

1. Open the Identity & Service Provider page.

Main Menu > Administration > Configure Soffid > Web SSO > Identity & Service providers

2. To add a new service provider, click on the Add Service Provider button.

Be in mind that you can configure more than one Entity Group and you could add new service providers in each one.

3. Then you must fill in the required fields. Also, you need to provide the identity provider metadata. You can either copy it from the Soffid federation page or instruct the service provider to download the federation metadata by itself.

image-1661408241083.png

For more information about the attributes, you can visit the CAS client detailed info.

Connecting Service Providers

Connecting Tacacs+

Introduction

TACACS (Terminal Access Controller Access Control System) is a security protocol that provides centralized validation of users who are attempting to gain access to a router or NAS

TACACS+ is a protocol for AAA services:

Register Tacas+

1. Open the Identity & Service Provider page.

Main Menu > Administration > Configure Soffid > Web SSO > Identity & Service providers

2. To add a new service provider, click on the Add Service Provider button.

Be in mind that you can configure more than one Entity Group and you could add new service providers in each one.

3. Then you must fill in the required fields. Also, you need to provide the identity provider metadata. You can either copy it from the Soffid federation page or instruct the service provider to download the federation metadata by itself.

image-1681221680349.png

For more information about the attributes, you can visit the Tacacs+ detailed info.

When a Tacacs Service Provider is created, Soffid creates an Information System

image-1681221732876.png

There are some roles defined for this Information System (0: anonymous, 1: user, ....15: root)

image-1681221803826.png

Connecting Service Providers

Connecting Radius client

Introduction

The Radius protocol (Remote Authentication Dial-In User Service) is a networking protocol that authorizes and authenticates users who access a remote network.

Register a Radius client

1. Open the Identity & Service Provider page.

Main Menu > Administration > Configure Soffid > Web SSO > Identity & Service providers

2. To add a new service provider, click the Add Service Provider button.

Be in mind that you can configure more than one Entity Group and you could add new service providers in each one.

3. Then, you must fill in the required fields. Also, you need to provide the identity provider metadata. You can either copy it from the Soffid federation page or instruct the service provider to download the federation metadata by itself.

image-1689336949656.png

For more information about the attributes, you can visit the Radius detailed info.

Web services reference

Web services reference

validate-domain

Definition
URL
Method
Headers
Authentication
Request (body JSON)
{
    "domain" : "arxus.eu"
}
Response (JSON)
{
    "exists": "yes",
    "identityProvider": "http://stasts-sof.arxus.eu/adfs/services/trust"
}


Web services reference

validate-credentials

Definition
URL
Method
Headers
Authentication
Request (body JSON)
{
    "user" : "edmond.halley",
    "password" : "12345",
    "identityProvider" : "my-service-provider",
    "serviceProviderName" : "https://idp.soffid.com",
    "sessionSeconds" : "3600"
}
Response (JSON)
{
    "valid": true,
    "sessionCookie": "_2307e8b5566ba600be64508a132f7f40c4578928733f2c3c:hRoFimsCGZSau7zjbWeVocTv13WAaui7dj00A7F39dM0R+daKHPQVi2WiAbhB/rV776S0TW5JXq7/9HjV0zo0h4E7AW72tCUD9I/8UD4VP5oTRWgR6xTP3mUwhn5NCuiHOE02kuITf6l3y6ZrUOBA6qVFo/Twlfhww9dZ2l7NrdrO/s3K40L",
    "attributes": {},
    "user": {
        "lastName": "Halley",
        "createdByUser": "csvIDs",
        "modifiedDate": "2017-12-15T11:01:02+01:00",
        "userType": "I",
        "shortName": "edmond.halley"
        },
    "identityProvider": "soffid"
}


Web services reference

expire-session

Definition
URL
Method
Headers
Authentication
Request (body JSON)
Response (JSON)
{
    "sessionId" : "_8164940b408c1508dfd84525a3ef568475f317085cf36e7d:rvJgZnMfsWUbQWlXdhTcVGgI3mC2qXJC..."
}


Web services reference

generate-saml-request

Definition

URL
Method
Headers
Authentication
Request (body JSON)
{
    "user" : "lucasfr@soffid.poc",
    "identityProvider" : "http://stasts-sof.arxus.eu/adfs/services/trust",
    "serviceProviderName" : "http://portal.arxus.com",
    "sessionSeconds" : "3600"
}
Response (JSON)
{
    "method": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
    "parameters": {
        "RelayState": "_457cab260c4948ef4c6d35a67cac000d3348d1ec48f53215",
        "SAMLRequest": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ
        wOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1sMnA9InVybjpvYXNpczpuYW1lczp
     	YzpTQU1MOjIuMDpwcm90b2NvbCIgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWN
        lVVJMPSJodHRwczovL3BvcnRhbC5hcnh1cy5jb206NDQzL1NBTUwtcmVzcG9uc2UiIEZvcmNlQXV0aG49ImZhbHNlI
        iBJRD0iXzQ1N2NhYjI2MGM0OTQ4ZWY0YzZkMzVhNjdjYWMwMDBkMzM0OGQxZ
        WM0OGY1MzIxNSIgSXNzdWVJbnN0YW50PSIyMDE4LTAxLTExVDEyOjEzOjA0L
        Y2NFoiIFZlcnNpb249IjIuMCI+PHNhbWwyOklzc3VlciB4bWxuczpzYW1sMj0idXJuOm9hc2lzOm5hbWVzOnRjOlN
        TUw6Mi4wOmFzc2VydGlvbiI+aHR0cDovL3BvcnRhbC5hcnh1cy5jb208L3NhbWwyOklzc3Vlcj48c2FtbDI6U3Via
        mVjdCB4bWxuczpzYW1sMj0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wO
        mFzc2VydGlvbiI+PHNhbWwyOk5hbWVJRCBGb3JtYXQ9InVybjpvYXNpczpuY
        W1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OmVtYWlsQWRkcmVzcyI+b
        HVjYXNmckBzb2ZmaWQucG9jPC9zYW1sMjpOYW1lSUQ+PC9zYW1sMjpTdWJqZ
        WN0Pjwvc2FtbDJwOkF1dGhuUmVxdWVzdD4="
}, 
    "url": "https://stasts-sof.arxus.eu/adfs/ls/"

}



Web services reference

parse-saml-response

Definition
URL
Method
Headers
Authentication
Request (URL parameter)
{
    "autoProvision" : false,
    "response" : {
        "RelayState": "_523866242f943b4c63234dc8942ffc2f08cea03aa129a4e2",
        "SAMLResponse": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ
        wOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1sMnA9InVybjpvYXNpczpuYW1lczp
        0YzpTQU1MOjIuMDpwcm90b2NvbCIgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWN
        lSW5kZXg9IjEiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly9hYmM6NDQzLy94eHgiIERlc3Rpb
        mF0aW9uPSJodHRwczovL3N0YXN0cy5hcnh1cy5ldS9hZGZzL2xzLyIgRm9yY2VBdXRobj0iZmFsc2UiIElEPSJfNTI
        zODY2MjQyZjk0M2I0YzYzMjM0ZGM4OTQyZmZjMmYwOGNlYTAzYWExMjlhNGU
        yIiBJc3N1ZUluc3RhbnQ9IjIwMTctMTItMjJUMTQ6NTU6MjAuODYyWiIgUHJvdG9jb2xCaW5kaW5nPSJ1cm46b2Fza
        XM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6SFRUUC1SZWRpcmVjdCIgV
        mVyc2lvbj0iMi4wIj48c2FtbDI6SXNzdWVyIHhtbG5zOnNhbWwyPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA
        6YXNzZXJ0aW9uIj5odHRwOi8vcG9ydGFsLmFyeHVzLmNvbTwvc2FtbDI6SXN
        zdWVyPjxzYW1sMjpTdWJqZWN0IHhtbG5zOnNhbWwyPSJ1cm46b2FzaXM6bmF
        tZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj48c2FtbDI6TmFtZUlEIEZvcm1
        hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm5hbWVpZC1mb3JtYXQ6cGVyc2lzdGVudCI+
        ZWRtb25kLmhhbGxleTwvc2FtbDI6TmFtZUlEPjwvc2FtbDI6U3ViamVjdD48L3NhbWwycDpBdXRoblJlcXVlc3Q+"
    },
    "protocol" : "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
    "serviceProviderName" : "https://stasts.arxus.eu/adfs/ls/"
}
Response (JSON)


Web services reference

generate-saml-logout-request

Definition

  • This operation allows to generate a SAML logout request to be sent to a IdP supporting SAML Global Logout, including Soffid IdP.

URL

  • <console-domain>/webservice/federation/rest/generate-saml-logout-request

Method

  • POST

Headers

  • Accept = “application/json”

  • Content-Type = “application/json”

Authentication

  • Use an account with federation:serviceProvider permission

Request (URL parameter)

  • user → Id of the user to log out

  • force → set to false if you want to give a chance to the end user to abort logout process. Set to true otherwise.

  • backChannel → set to true if you want to send the logout process via SOAP to the identity provider. Set to false if you want to send the logout process using a Redirect or HTML Form. The later allows interaction between the end user and the identity provider.

  • serviceProviderName → service provider that notifies user logout

  • identityProvider → identity provider to send the logout request

Response (JSON)

  • parameters → parameters to send to identity provider.

    • RelayState → identifier of the request id

    • SAMLRequest → encoded SAML request

  • method → method to use: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect or urn:oasis:names:tc:SAML:2.0:bindings:SOAP

  • url → url where to send the request

Samples

Sample request

{
    "user": "my-id",
    "force": true,
    "backChannel": false,
    "serviceProviderName":"my-identity-provider",
    "identityProvider":"http://idp.soffid.com"
}

Sample response

{
    "url":"https://idp.soffid.com/SAML/SLO/SOAPBinding",
    "method":"urn:oasis:names:tc:SAML:2.0:bindings:SOAP",
    "parameters": {
        "RelayState":"_523866242f943b4c63234dc8942ffc2f08cea03aa129a4e2",
        "SAMLResponse": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ...."
    }
}

Sample redirect method made by service provider (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect method)

HTTP/1.1 302 Found
Location: https://idp.soffid.com/SAML/SLO/RedirectBinding?RelayState=_523866242f943b4c63234dc8942ffc2f08cea03aa129a4e2&SAMLRequest=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ....

Sample html form made by service provider (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST method)

<html>
    <body onLoad="document.forms[0].submit();">
        <form action="https://idp.soffid.com/SAML/SLO/PostBinding">
            <input type="hidden" name="RelayState" value="_523866242f943b4c63234dc8942ffc2f08cea03aa129a4e2"/>
            <input type="hidden" name="SAMLRequest" value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJ..."/>
        </form>
    </body>
</html>

Sample SOAP request ( urn:oasis:names:tc:SAML:2.0:bindings:SOAP method ). Service provader decodes SAMLRequest, and includes it in a SOAP message.

POST /SAML/SLO/SoapBinding HTTP/1.1
Host: idp.soffid.com
Content-Type: text/xml
Content-Length: ....
SOAPAction: http://www.oasis-open.org/committees/security
 
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
 <SOAP-ENV:Body>
   <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="d2b7c388cec36fa7c39c28fd298644a8" IssueInstant="2004-01-21T19:00:49Z" Version="2.0">
     <Issuer>your-identity-provider</Issuer>
     <NameID Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent">005a06e0-ad82-110d-a556-004005b13a2b</NameID>
     <samlp:SessionIndex>1</samlp:SessionIndex>
   </samlp:LogoutRequest>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Connecting Office 365

Introduction

You can use an Identity Provider defined into Soffid to connect to Office 365. You only need to register the Office 365 metadata into a Soffid Service Provider and register the Identity Provider Metadata into your Office 365.

At this tutorial Soffid explain how to connect to Office 365 using PowerShell.

Step By Step

Attribute definition

Review the attribute definition to check if it will be necessary to add the Required attributes.

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp

Attribute sharing policies

Review the attribute sharing policies to add the required attributes.

Option 1

Soffid will be in charge of creating users in Office 365.

1. First of all, you need to configure your Identity Provider, in that case, we configure Soffid as Identity Provider.

image-1644228339942.png

image-1644228359906.png

2. Then, you need to configure the Service provider. It will be mandatory to copy the Metadata of Office 365 into the Service Configuration.

image-1644228483247.png

3. You need to configure an Office 365 agent: https://bookstack.soffid.com/books/connectors/page/how-to-configure-the-office-365-agent

Option 2

The Active Directory will be in charge of creating users in Office 365.

1. You need to create the attribute inmutableId in the agent configuration

image-1681898221429.png

If you fetch the Soffid object, Soffid will display this new attribute

image-1681898371943.png

2. You must add a UID Script in the Office 365 Service Provider  

image-1681898502855.png

System.out.printlin("Guessing immutable id for " + id + "/" + userName);
for (account: serverService.getUserAccounts(id, "ActiveDirectoryDemoLab")) {
  if (account.attributes{"immutableId"} != null) 
    return account.attributes{"immutableId"};
}

PowerShell

If necessary you can install the Azure AD module for Windows PowerShell

Install-Module MSOnline

Then you can connect to the service

Connect-MsolService

When you executed the connect method, a new window will open to login Microsoft in as an administrator domain user.

image-1643903332457.png

Once you have logged in, you could execute some commands to configure the connection to Office 365: 

In order to connect to Office 365, one can use the following script:

$dom = "<Your demain>"
$BrandName = "<Your company>"
$LogOnUrl = "https://<Your Soffid IdP>/profile/SAML2/POST/SSO"
$LogOffUrl = "https://<Your Soffid IdP>/profile/SAML2/POST/SLO"
$ecpUrl = "https://<Your Soffid IdP>/SAML2/POST/PAOS"
$MyURI = "<Your Soffid IdP>"
$MySigningCert = "<Your certificate in Base64>";
# "MIIGaDCCBVCgAwIBAgIQAWdkq9pxzP/bK+Mlym5y5zANBgkqhkiG9w0BAQsFADBeMQswCQY....
$Protocol = "SAMLP"
 
# To enable
Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $LogOnUrl -SigningCertificate $MySigningCert -IssuerUri $MyURI -LogOffUri $LogOffUrl -PreferredAuthenticationProtocol $Protocol
 
# To disable
# Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed

https://docs.microsoft.com/en-us/powershell/module/cimcmdlets/?view=powershell-7.2

https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-msonlinev1?view=azureadps-1.0#install-the-azure-ad-module

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp


Server certificate management


There are two options for certificate management

1. The easiest, fast and cheap one: Do not create any public or private key, nor enter any certificate chain. At first start up, Soffid Identity Provider will generate a new public/private key pair. Using this key, Soffid IdP will create a self-signed certificate and will store it on the certificate chain field.

2. The secure one: 

2.1. Create a public/private key.

2.2. Generate a PKCS#10 file. Use this file to ask for a certificate to a well known certificate authority.

2.3. After some paper work, the certificate authority will give you a valid certificate.

2.4. The certificate can be in PEM or DER format. If it's in PEM format, it will start with a line saying

------BEGIN CERTIFICATE ----
In such a case, just paste its contents on certificate chain field.
If it's in binary DER format, you can use openssl to convert it from PEM to DER:
openssl x509 -in <DER-FILE> -inform DER -out <PEM-FILE> -outform PEM
Sometimes your CA will give you a base64 encoded DER file. In such a case, convert it to PEM using:
openssl base64 -d <DEF-FILE> | openssl x509 -inform DER -out <PEM-FILE> -outform PEM

Identity Broker

Identity Broker

Soffid IdP as an identity broker

Introduction

An Identity Broker is often part of a a Single Sign-On Architecture as an an intermediary service that connects multiple Service Providers with different Identity Provider (IDP)s.​

Soffid IdP can act as an identity broker. This means that Soffid IdP can rely on third party identity providers to identify users.

To act as an identity broker, the External SAML identity provider option must be enabled on the Authentication page. You can visit the Authentication page for more info.

Data flow

The following diagram, shows the resulting data flow between the end user, your application, the identity provider and Soffid web services:


Data flow steps

1. Web browser requests a protected web application resource.

2. Web application builds a SAML authentication request and forwards it to Soffid IdP.

3. Soffid IdP receives SAML authentication request and validates it. A user name and password page is presented. This page can optionally contain a set of links to third-party identification servers.

If the user clicks on the third party identification server link, or the typed in user name is expected to be authenticated by a third-party IdP. Soffid IdP acts as a Service Provider and an authentication request is forwarded to that IdP. The authentication request format depends on the protocol required by the third-party IdP.

4. Third-party IdP receives the authentication request and presents the user its user name and password page.

5. User fills in the user name and password form.

6. Third-party IdP builds an authentication response that is forwarded to Soffid IdP. This response can contain a SAML Assertion or a oAuth authorization token.

7. Soffid IdP parses and validates the received response:

7.1. For SAML responses, the assertion is validated and identity attributes are extracted.

7.1. For oAuth responses, the authorization token is used to get a session token. Next, session token is used to fetch user attributes from external IdP.

7.1. For OpenID-Connect responses, the authorization token is used to get a session token along the OpenID token received. The OpenID token is parsed as a JWT token, and each claimed attribute is parsed.

8. Soffid IdP finds the identity owner of the external identity. If no identity is found, depending on Soffid IdP configuration, it can automatically create a Soffid Identity based on received attributes.

9. Finally, Soffid IdP issues a SAML assertion containing Soffid identity attributes.


https://ldapwiki.com/wiki/Identity%20Broker

Identity Broker

External oAuth / OpenID Identity Providers

Introduction


Soffid federation can be composed by a mix of SAML and oAuth / OpenID-connect servers. In such a scenario, Soffid IdP is able to let users be identified by oAuth servers like Linked-in, Google or Facebook, perform all the provision tasks required and send back a SAML assertion to the service provider requiring user authentication.

To create an external oAuth identity provider, you can choose the Idp type from a list of popular sites, like Google or Facebook, or write you own descriptor.

The descriptor should follow the OpenID connect discovery JSON document. Most parameters are optional, but these are required:

Next, you must register Soffid IdP with your oAuth server. After registering, you will get a oAuthKey (some kind of username) and an oAuthSecret (some kind of password). To register Soffid IdP, your oAuth server will require you to specify the redirection endpoint. This redirection endpoint refers to your Soffid IdP and will receive the authorization token generated by the oAuth server.

If your Soffid IdP is listening to https://idp.yourdomain.com:2443/, your redirection endpoint will be https://idp.yourdomain.com:2443/oauthResponse

As an example, here you have some links to get your oAuth keys and secrets for Google, Facebook and Linkedin.


Holder group login


Holder group login

Holder group login

Introduction

In some organizations is necessary to assign roles that affect only a part of the structure, for instance, a department, a division or a country. A Holder Group can be defined as a collection of entities (referred to as "holders") that share similar characteristics, roles, permissions, or access requirements. The concept of a Holder Group simplifies the management of identities by enabling administrators to apply policies, assign roles, and manage permissions at the group level rather than individually.

The Soffid federation allows a new way to login, the Holder group login. This new way, allows the user to login to applications, Service Provider, indicating with which group the user wants to log in. Soffid will share with the application the roles and permissions according to the selected group.

If you want an application to allow Holder group login, the option Ask for group membership after authentication of the Service Provider must be activated (Yes option selected).

Once the user has logged in using the federation, Soffid will share with the Service Provider application the following information:

How Holder group login works?

1. The user is not logged in to the Identity Provider.

1.1. The user type the user and password into the Identity Provider.

1.2. The Identity Provider validates the user credentials, and requires a 2FA if it is necessary.

1.2.1. If the credentials are not correct, an error message is displayed.

1.2.2. If the credentials are correct, the Identity Provider get a list of all groups to which the user can log in. This list is obtained by selecting all groups, primary and/or secondary, that have as type one with Rol holder Yes. The groups are not repeated in this list.

1.2.2.1. If there is no group with these characteristics, the Identity Provider automatically logs the user, and shares the data with the Service Provider.

1.2.2.2. If there is only one group with these characteristics, the Identity Provider automatically logs the user into this group, and shares the data with the Service Provider.

1.2.2.3. If there is more than one group, the Identity Provider displays a list of the groups for the user to select which one to log in to. Here the user selects the group and logs in, then Identity Provider shares the updated data with the Service Provider.

2. The user is already logged in to the Identity Provider.

2.1. The user login to a new application, Service Provider.

2.2. The Identity Provider checks if there are any additional adaptive rules required to perform the login.

2.2.1. If the credentials are not correct, an error message is displayed.

2.2.2. If the credentials are correct, the user logs in to the application with the group to which the user was previously logged in. The Identity Provider shares the updated data with the Service Provider, so if there have been any changes in the user's roles, these updates are reflected in the shared data.

Service providers that allow Holder group login

The following Service Providers allow you to configure the login with Holder group

Holder group login

Steps to configure

Steps to configure

1. Group type: Create at least one organizational unit with the role holder attribute active (yes).

image.png

https://bookstack.soffid.com/books/soffid-3-reference-guide/page/group-type

2. Groups: Assign Groups to the organizational unit. Define groups with the appropriate group type.

image.png

https://bookstack.soffid.com/books/soffid-3-reference-guide/page/groups

3. Custom attributes: (Optional) You can include new custom attributes to this membership relationship, go to Metadata page and select the GroupUser to add these attributes.

4. Attribute definition: Define the Attributes to deliver from the identity providers to the service providers

4.1. Holder group

image.png

4.2. Role & group membership

image.png

5. Attribute sharing policies: Define the policies to share the attributes with each service provider.

In this case, the Holder group, and Role & group membership attributes will be always shared. 

image.png

6. Service Provider: Configure the service providers, indicating in which ones the headline group should be requestedimage.png

Holder group login

Use cases

Premises

1. An Organizational Unit has been defined as Role holder Yes.

image.png

2. Several groups have been defined with type organizational unit with role holder Yes.

image.png

3. An attribute sharing policy has been defined.

image.png

4. Indicates which Service Providers will be required group membership after authentication.

image.png

Use cases

Use case 1 - Log in to an application

User with no groups, Primary or Secundary, with type holder group Yes. When this user log into an application --> The user login normally to the application

Use case 2 - Log in to an application

User with only one group, Primary or Secondary, with type holder group Yes. This users can have more groups with holder group No. When this user logs in to an application  --> The user will be loged-in the application with the group with type holder group yes.

OpenID-Connect

a. User Agatha with Primary group RRHH (Role holder Yes)

image.png

image.png

image.png

b. Login: the user type the user and password to login

 image.png

c. Get the JSON id_token

image.png

d. Decode the JSON Web Token using  https://jwt.io

Here you are the scope, the holder_group and the member_of data

{
  "sub": "agatha",
  "iss": "https://sync-server.netcompose:1443",
  "holder_group": "RRHH",
  "meber_of": [
    "SOFFID_HOLDER_CONDOMAIN004/RRHH@soffid",
    "SOFFID_HOLDER_CONDOMAIN005/Philosophers@soffid",
    "SOFFID_VAULT_USER@soffid",
    "SOFFID_HOLDER_CONDOMAIN004/Writers@soffid",
    "SOFFID_USER@soffid"
  ],
  "nonce": null,
  "sid": "oeB51Jr/+rb5yE+lbG9iYsAHy1TxOFYm",
  "aud": "angularApp",
  "azp": "angularApp",
  "auth_time": 1737365621,
  "scope": "openid profile email",
  "exp": 1737366221,
  "iat": 1737365622,
  "jti": "WW1wwRD-HaE9DCXfQv4wLRuFgGRbI1lB_9wDFBd6X4ILJBv4vS6mL1yG3S0Ee_Nv",
  "email": "agatha@soffid.com"
}

SAML

a. User Agatha with Primary group RRHH (Role holder Yes)

image.png

image.png

image.png

b. Login: the user type the user and password to login

 image.png image.png

c. Get the SAML response 
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://pat.soffid.lab:8443/soffid/saml/log/post" ID="_6699870c490dcef896cb33d70187de62" InResponseTo="_edec4bcc9b7bf081e970867995369df9" IssueInstant="2025-01-20T09:35:53.249Z" Version="2.0">
 <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sync-server.netcompose</saml2:Issuer>
 <saml2p:Status>
  <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"></saml2p:StatusCode>
 </saml2p:Status>
 <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_8d730eeaaa1bcfbf419568e5edc77d27" IssueInstant="2025-01-20T09:35:53.249Z" Version="2.0">
  <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sync-server.netcompose</saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:SignedInfo>
    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
    <ds:Reference URI="#_8d730eeaaa1bcfbf419568e5edc77d27">
     <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
       <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"></ec:InclusiveNamespaces>
      </ds:Transform>
     </ds:Transforms>
     <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
     <ds:DigestValue>qEEAkYqFFZxatl6DaVme4IfrojC3zafaKFH+TpIDurY=</ds:DigestValue>
    </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>TeVSWaALsRLMwYxi71/b1k8jKYOrFb7qS9qva2T5T3yKpNLwZxnmRqWznbBM7wpr9U3V0scfh5M1ex/NGflbADbxih7uwUVK8YSAZPwIx/4LXEx0uOxpQi7ZiDOvhb2jkKLdvztvUkBGeJhJGCJy/2WrOHIEdzsn4T4c7TBdWZc=</ds:SignatureValue>
   <ds:KeyInfo>
    <ds:X509Data>
     <ds:X509Certificate>MIICKTCCAZKgAwIBAgIGAY3q71O5MA0GCSqGSIb3DQEBCwUAMFgxJzAlBgNVBAMMHmh0dHBzOi8v
c3luYy1zZXJ2ZXIubmV0Y29tcG9zZTEcMBoGA1UECwwTRmVkZXJhdGlvbiBzZXJ2aWNlczEPMA0G
A1UECgwGU09GRklEMB4XDTI0MDIyNzE0MjkyOVoXDTM0MDIyNzE0MjkyOVowWDEnMCUGA1UEAwwe
aHR0cHM6Ly9zeW5jLXNlcnZlci5uZXRjb21wb3NlMRwwGgYDVQQLDBNGZWRlcmF0aW9uIHNlcnZp
Y2VzMQ8wDQYDVQQKDAZTT0ZGSUQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJZ5G9BnTSLh
X8VOVbdyY01EUkgHexi97+e1iGA0r1WM6cTu4Ku3k7/efIB5ZZfteRKbPwa719y8Ytb5W4RFcZ6O
XzHz9o+FhG64tZHEo4xwVdukv6rOatSSlhomEhruhxX+x7OpFnnlXNSCypi1xjEQyIm8GJKxpxjk
RJvkgfXLAgMBAAEwDQYJKoZIhvcNAQELBQADgYEATbs8iLBYEcPdPBjtmNHYrQpXb3nc83Acmxyy
/pEe4hXaMoB1rBuxNf47IiqJaJld9H6k5oXWcGgG8FyrdOxpY3eE8cw1s+6tM/MACMRuhuV4bQhR
FD1aizcW6fQUfvmkRLUgS1o8BMZZjCWW22FPeSklFXATE/FvmncRGpT9JWs=</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </ds:Signature>
  <saml2:Subject>
   <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://sync-server.netcompose">Agatha</saml2:NameID>
   <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <saml2:SubjectConfirmationData Address="172.18.0.1" InResponseTo="_edec4bcc9b7bf081e970867995369df9" NotOnOrAfter="2025-01-20T09:40:53.249Z" Recipient="https://pat.soffid.lab:8443/soffid/saml/log/post"></saml2:SubjectConfirmationData>
   </saml2:SubjectConfirmation>
  </saml2:Subject>
  <saml2:Conditions NotBefore="2025-01-20T09:35:53.249Z" NotOnOrAfter="2025-01-20T09:40:53.249Z">
   <saml2:AudienceRestriction>
    <saml2:Audience>https://pat.soffid.lab:8443/soffid-iam-console</saml2:Audience>
   </saml2:AudienceRestriction>
  </saml2:Conditions>
  <saml2:AuthnStatement AuthnInstant="2025-01-20T09:35:53.197Z" SessionIndex="_cd9afa8aac3a7a35abc90b488b01d458">
   <saml2:SubjectLocality Address="172.18.0.1"></saml2:SubjectLocality>
   <saml2:AuthnContext>
    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
   </saml2:AuthnContext>
  </saml2:AuthnStatement>
  <saml2:AttributeStatement>
   <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">agatha@soffid.com</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Agatha</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="memberOf" Name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_HOLDER_CONDOMAIN004/RRHH@soffid</saml2:AttributeValue>
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_HOLDER_CONDOMAIN005/Philosophers@soffid</saml2:AttributeValue>
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_VAULT_USER@soffid</saml2:AttributeValue>
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_HOLDER_CONDOMAIN004/Writers@soffid</saml2:AttributeValue>
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_USER@soffid</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="HolderGroup" Name="urn:oid:1.3.6.1.4.1.22896.3.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">RRHH</saml2:AttributeValue>
   </saml2:Attribute>
  </saml2:AttributeStatement>
 </saml2:Assertion>
</saml2p:Response>

Use case 3 - Log in to an application

User with more than one group, Primary or Secondary, with type holder group Yes. When this user log into an application  --> The user will have to choose the holder group to login the application. The user will be loged-in the application with the holder group selected.

OpenID-Connect

a. User Agatha with three groups with Role holder Yes

image.png

image.png

b. Login: the user type the user and password to login

 image.png

c. The user has to select the holder group to login

image.png

d. Get the JSON id_token

 image.png

 

e. Decode the JSON Web Token using  https://jwt.io

Here you are the scope, the holder_group and the member_of data

{
  "sub": "agatha",
  "iss": "https://sync-server.netcompose:1443",
  "holder_group": "Marketing",
  "meber_of": [
    "SOFFID_VAULT_USER@soffid",
    "SOFFID_HOLDER_CONDOMAIN005/Writers@soffid",
    "SOFFID_USER@soffid"
  ],
  "nonce": null,
  "sid": "+cr0VQjIUcwmuJg0jraIO4DwtPfFOH9b",
  "aud": "angularApp",
  "azp": "angularApp",
  "auth_time": 1737366858,
  "scope": "openid profile email",
  "exp": 1737367458,
  "iat": 1737366858,
  "jti": "X1kvNUqr_-LJgz_EHneva0-mtHTLSkhN00d3UX-dtA7LVcjpkyM0yvl5UPst9vV2",
  "email": "agatha@soffid.com"
}

SAML

a. User Agatha with three groups with Role holder Yes

image.png

image.png

b. Login: the user type the user and password to login

 image.png image.png

c. The user has to select the holder group to login

image.png

d. Get the SAML response 
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://pat.soffid.lab:8443/soffid/saml/log/post" ID="_82e187f91ad03509cbb5adc502dc75ec" InResponseTo="_5ffefaae23a7626917de0e0d8c4866e5" IssueInstant="2025-01-20T09:56:45.504Z" Version="2.0">
 <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sync-server.netcompose</saml2:Issuer>
 <saml2p:Status>
  <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"></saml2p:StatusCode>
 </saml2p:Status>
 <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_f351bb2c2cb39df3eeb29f31f4e6ea02" IssueInstant="2025-01-20T09:56:45.504Z" Version="2.0">
  <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sync-server.netcompose</saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:SignedInfo>
    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
    <ds:Reference URI="#_f351bb2c2cb39df3eeb29f31f4e6ea02">
     <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
       <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"></ec:InclusiveNamespaces>
      </ds:Transform>
     </ds:Transforms>
     <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
     <ds:DigestValue>FIIpGC4P+i4OYv+1MxIw2tdgPgheB6zsE2QhbHTUP3U=</ds:DigestValue>
    </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>VI2a9cx7vPKH+fppjyRQ4g+/NPknfxVzgbekaWomAxHvgNegRonlalUiRiiVLC5DdcT1dkO85c9FJgf5x8CgEfKFRKVNcaNWRVMZIZYUR/DKjyVH0F8a8lZMdHyxB9z3xj0QVqs7536dalA38hD5p4TG4PoNttYLhE1tFGd8QsI=</ds:SignatureValue>
   <ds:KeyInfo>
    <ds:X509Data>
     <ds:X509Certificate>MIICKTCCAZKgAwIBAgIGAY3q71O5MA0GCSqGSIb3DQEBCwUAMFgxJzAlBgNVBAMMHmh0dHBzOi8v
c3luYy1zZXJ2ZXIubmV0Y29tcG9zZTEcMBoGA1UECwwTRmVkZXJhdGlvbiBzZXJ2aWNlczEPMA0G
A1UECgwGU09GRklEMB4XDTI0MDIyNzE0MjkyOVoXDTM0MDIyNzE0MjkyOVowWDEnMCUGA1UEAwwe
aHR0cHM6Ly9zeW5jLXNlcnZlci5uZXRjb21wb3NlMRwwGgYDVQQLDBNGZWRlcmF0aW9uIHNlcnZp
Y2VzMQ8wDQYDVQQKDAZTT0ZGSUQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJZ5G9BnTSLh
X8VOVbdyY01EUkgHexi97+e1iGA0r1WM6cTu4Ku3k7/efIB5ZZfteRKbPwa719y8Ytb5W4RFcZ6O
XzHz9o+FhG64tZHEo4xwVdukv6rOatSSlhomEhruhxX+x7OpFnnlXNSCypi1xjEQyIm8GJKxpxjk
RJvkgfXLAgMBAAEwDQYJKoZIhvcNAQELBQADgYEATbs8iLBYEcPdPBjtmNHYrQpXb3nc83Acmxyy
/pEe4hXaMoB1rBuxNf47IiqJaJld9H6k5oXWcGgG8FyrdOxpY3eE8cw1s+6tM/MACMRuhuV4bQhR
FD1aizcW6fQUfvmkRLUgS1o8BMZZjCWW22FPeSklFXATE/FvmncRGpT9JWs=</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </ds:Signature>
  <saml2:Subject>
   <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://sync-server.netcompose">Agatha</saml2:NameID>
   <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <saml2:SubjectConfirmationData Address="172.18.0.1" InResponseTo="_5ffefaae23a7626917de0e0d8c4866e5" NotOnOrAfter="2025-01-20T10:01:45.504Z" Recipient="https://pat.soffid.lab:8443/soffid/saml/log/post"></saml2:SubjectConfirmationData>
   </saml2:SubjectConfirmation>
  </saml2:Subject>
  <saml2:Conditions NotBefore="2025-01-20T09:56:45.504Z" NotOnOrAfter="2025-01-20T10:01:45.504Z">
   <saml2:AudienceRestriction>
    <saml2:Audience>https://pat.soffid.lab:8443/soffid-iam-console</saml2:Audience>
   </saml2:AudienceRestriction>
  </saml2:Conditions>
  <saml2:AuthnStatement AuthnInstant="2025-01-20T09:56:45.461Z" SessionIndex="_31bb4c1105aa3c363a69b299e577d9cd">
   <saml2:SubjectLocality Address="172.18.0.1"></saml2:SubjectLocality>
   <saml2:AuthnContext>
    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
   </saml2:AuthnContext>
  </saml2:AuthnStatement>
  <saml2:AttributeStatement>
   <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">agatha@soffid.com</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Agatha</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="memberOf" Name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_VAULT_USER@soffid</saml2:AttributeValue>
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_HOLDER_CONDOMAIN005/Writers@soffid</saml2:AttributeValue>
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">SOFFID_USER@soffid</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="HolderGroup" Name="urn:oid:1.3.6.1.4.1.22896.3.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Marketing</saml2:AttributeValue>
   </saml2:Attribute>
  </saml2:AttributeStatement>
 </saml2:Assertion>
</saml2p:Response>

Use case 4 - Log in to a second application

a. Agatha user was previously loged-in to an application

Agatha user is loged-in the angularApp Service Provider

{
  "sub": "agatha",
  "iss": "https://sync-server.netcompose:1443",
  "holder_group": "Marketing",
  "meber_of": [
    "SOFFID_VAULT_USER@soffid",
    "SOFFID_HOLDER_CONDOMAIN005/Writers@soffid",
    "SOFFID_USER@soffid"
  ],
  "nonce": null,
  "sid": "+cr0VQjIUcwmuJg0jraIO4DwtPfFOH9b",
  "aud": "angularApp",
  "azp": "angularApp",
  "auth_time": 1737366858,
  "scope": "openid profile email",
  "exp": 1737367458,
  "iat": 1737366858,
  "jti": "X1kvNUqr_-LJgz_EHneva0-mtHTLSkhN00d3UX-dtA7LVcjpkyM0yvl5UPst9vV2",
  "email": "agatha@soffid.com"
}
b. Agata user is loged-in to a second application

 Agatha user is loged-in the OpenIDConnectApp001 Service Provider, with the same holder group

{
  "sub": "agatha",
  "iss": "https://sync-server.netcompose:1443",
  "holder_group": "Marketing",
  "meber_of": [
    "SOFFID_VAULT_USER@soffid",
    "SOFFID_HOLDER_CONDOMAIN005/Writers@soffid",
    "SOFFID_USER@soffid"
  ],
  "nonce": null,
  "sid": "WDSQEzO6LIgxvQkq/zyIzL/LddKKy/j0",
  "aud": "OpenIDConnectApp001",
  "azp": "OpenIDConnectApp001",
  "auth_time": 1737367082,
  "scope": "openid",
  "exp": 1737367683,
  "iat": 1737367083,
  "jti": "C5xSE7UK0lgwgff5Cl7SPnpZvcRSm8WI0GZMXXObKdCMOuP50qbZjCcuGW7KpJqN",
  "email": "agatha@soffid.com"
}