Authentication
The Orchestrator supports three authentication methods. These methods are:
SRP
The SRP (Secure Remote Password) protocol is used as the default authentication mechanism, providing a secure and decentralized approach that does not rely on an external identity provider.
SRP ensures that user passwords are never transmitted to the Orchestrator, enhancing security by mitigating the risk of password interception. Instead of storing passwords, the Orchestrator securely stores a salt and a verifier derived from the user's password during the registration process. This approach ensures that sensitive credentials are not exposed or directly stored, aligning with best practices for secure authentication.
Links: SRP RFC, Protocol design, TLS-SRP RFC
The orchestrator is currently using the thinbus SRP library.
SAML
SAML (Security Assertion Markup Language) is a standard protocol that enables users to log in to applications based on their active sessions in another system, typically an identity provider (IdP). It facilitates Single Sign-On (SSO) by transferring authentication and authorization data securely.
The current implementation of the Orchestrator utilizes the Dead Simple SAML Client library, which simplifies retrieving authenticated user identities from any compliant identity provider. This library manages the SAML authentication process and handles integration with the SAML protocol.
A typical SAML authentication workflow involves the following steps:
SAML Request: Orchestrator (Service Provider) generates a SAML authentication request and sends it to the Identity Provider.
User Authentication: The Identity Provider authenticates the user based on its session or other mechanisms.
SAML Response: The Identity Provider returns a signed SAML response to Orchestrator, asserting the user’s identity and any associated attributes.
Both the SAML request and the SAML response are exchanged using HTTP POST requests, typically facilitated through the user's browser.
oAuth2
OAuth 2.0 (OAuth2) is an open-standard protocol for authorization that enables secure, delegated access to resources on behalf of a user. It allows applications (clients) to access resources hosted on another server (resource server) without sharing the user's credentials (e.g., password). Instead, OAuth2 uses access tokens, which grant specific permissions for a limited time.
To enable OAuth2 authentication, the Orchestrator uses the Vert.x OAuth2 client configured with the Authorization Code Flow. This setup ensures secure interaction between the client and the authorization server, adhering to OAuth2 standards for obtaining access tokens.
The workflow:
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
SAML and oAuth2 user creation policies
The Orchestrator offers three policies for creation authenticated users in Olympe database. The desired policy can be configured using the SAML_POLICY Docker parameter. Below are the available options:
STATELESS_EXISTING_USERS(default): When a user with a specified nameID successfully logs in via the IDP, there must already be a corresponding user node in Olympe database with the coresponding nameID. If no such user node exists, an error is thrown.CREATE_USERS_FROM_IDPWhen a user with a nameID successfully logs in via the IDP and no corresponding user exists in Olympe database, a new user is automatically created.STATELESS_ASSIGN_TO_PREDEFINED_USERRegardless of the nameID provided during IDP login, the user is mapped to a predefined user in Olympe database. This predefined user must already exist in the database. To configure this policy, you need to set the prefediened user tag.
Configuration of SAML and oAuth2
We can configure and run multiple SSO providers simultaneously.
Docker variable: SSO_CONFIGURATIONS
The docker value:
{
"saml": {
"enabled": true, // true if the saml authentication is enabled
"config": [
{
"idpName": "idp_name", // the given SSO name
"samlLogoutIDPEnabled": true, // true if the logout from IDP is enabled
"samlConsumerURL": "https://my-application.fluidapp.io/OlympeServer/rest/acs", // the orchestrator http endpoint to receive the SAML response
"samlMetaData": "metadata.xml", // the path to the metadata file with the SSO configuration
"samlIssuerName": "my-application", // the issuer name
"userRoleTag": ["ff011000000000000001"], // Newly created users will be assigned to these roles, by default user is assign to Atuhenticated user role and Project runner user role
"userTag": "user_tag", // Only for STATELESS_ASSIGN_TO_PREDEFINED_USER policy, the user which will be assign to every authenticated user
"userPolicy": "STATELESS_ASSIGN_TO_PREDEFINED_USER", // the user creation policies
"samlAllowGroups": ["my_group"] // Orchestrator will authenticate users only if they belong to specified groups. These groups are validated against the groups attribute in the SAML response.
}
]
},
"oAuth2": {
"enabled": true, // true if the oAuth2 authentication is enabled
"config": [
{
"idpName": "idp_name", // the given SSO name
"providerURL": "sso_url", // the url to the SSO endpoint to initialize authentication
"clientId": "client id", // the client ID
"clientSecret": "client secret", // the client secret
"authorizationPath": "authorize_url", // the url to the SSO endpoint to authorize
"revocationPath": "revoke_url", // the url to the SSO endpoint to revoke authentication
"endSessionPath": "end_session_url", // the url to the SSO endpoint to end session
"ssoLogoutPath": "logout_url", // the url to the SSO endpoint to logout
"tokenPath": "token_url", // the url to the SSO endpoint to get token
"userInfoPath": "info_url", // the url to the SSO endpoint to retrieve profile information and other attributes for a logged-in end-user.
"jwksURI": "jwk_url", // the url to retrieve the public server JSON Web Key (JWK) to verify the signature of an issued token or to encrypt request objects to it.
"scope": "scope", // a scope defines the specific permissions or access levels that a client application is requesting on behalf of a user. Scopes are used to limit an application's access to a user's resources and are often associated with API endpoints.
"callbackPath": "https://my-application.fluidapp.io/OlympeServer/rest/openid/callback", // the orchestrator http endpoint to receive the oAuth2 response, please make sure that this endpoint is unique for each configuration
"userPolicy": "STATELESS_ASSIGN_TO_PREDEFINED_USER", // the user creation policies
"userRoleTag": ["ff011000000000000001"], // Newly created users will be assigned to these roles, by default user is assign to Atuhenticated user role and Project runner user role
"userTag": "user_tag", // Only for STATELESS_ASSIGN_TO_PREDEFINED_USER policy, the user which will be assign to every authenticated user
"userIdClaim": "upn" // the user claim ID refers to the claim in the token that uniquely identifies the user associated with the token. This claim is a key piece of information for orchestrator to know which user is making the request.
}
]
}
}