Advanced Server Config

Authentication

Normally MIRACL Trust SSO server acts as an identity provider (IdP) and authenticates against MIRACL Trust Portal trought OIDC (which is the default authentication configuration):

authentication:
  oidc:
    miracl:
      client_id: ""
      client_secret: ""

The authentication to the IdP server could be setup to proceed to another IdP which supports either SAML or OIDC protocol. The authentication configuration should reflect this following some rules as seen below.

The redirect URL of the SSO is dynamically created depending on the authentication configuration. It is structured as https://<yourssoip>/auth/PROTOCOL/NAME (i.e. https://<yourssoip>/auth/oidc/miracl for the example above).

  • PROTOCOL should be either oidc or saml depending on the authentication protocol you’re authenticating against to the IdP server.
  • NAME should be the name you have setup the authentication server with.

OIDC IdP authentication

If you want to authenticate against another OIDC servers as an IdP, you need to configure it as follows:

authentication:
  oidc:
    NAME:
      client_id: ""
      client_secret: ""
      issuer: ""
      scope: "openid email profile"
      allow_unknown_state: false
  • NAME is the name of the IdP server and participates in the redirect url.
  • client_id and client_secret should be the credentials to the OIDC IdP app.
  • issuer should be the issuer identifier URI of the IdP. If not set, it has a default value pointing to MIRACL MFA Platform.
  • scope contains the claim values you’d like to have returned for the authenticated user of IdP. By default it is “openid email profile”.
  • allow_unknown_state disables the matching of the OIDC state during the OIDC authentication. Its default value is false.

SAML IdP authentication

There are cases when you’d want to use MIRACL Trust SSO server as a proxy between a service provider (SP) and another IdP supporting SAML for authentication. Then you need to configure our server to use SAML authentication to the IdP, i.e. to act as an SP to the IdP. This is done by:

authentication:
  saml:
    NAME:
      entity_id: "Your IdP Entity ID"
      idp_metadata: |-
        <!-- insert IdP metatadata here or use *idp_metadata_url* to link it -->
      allow_idp_initiated: true
      certificate: |-
        -----BEGIN CERTIFICATE-----
        MIIDbDCCAlSgAwIBAgIGAWkz3Fw1MA0GCSqGSIb3DQEBCwUAMHcxFDASBgNVBAoTC0dvb2dsZSBJ        
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        otero2Uksx3F/9g6PtyQx2WRah4A8eA9kQ==
        -----END CERTIFICATE-----
      key: |-
        -----BEGIN PRIVATE KEY-----
        MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDQ+oPbjugJroh7FavDAR2McYtj
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        HbpMNg17/p8b9Za7IROLV4Ypd7sb
        -----END PRIVATE KEY-----
  • NAME is the name of the IdP server and participates in the redirect url.
  • entity_id should be the identifier of an entity that provides SAML-based services.
  • Either idp_metadata_url or idp_metadata should be set with the IDP metadata.
  • allow_idp_initiated specifies should an IDP initiated flow is allowed to this SP connection, by default is true.
  • certificate and key are the RSA public base64 encoded x509 certiricate and private key of our SSO used for signing SAML requests to the IdP.

Rules

There could be configured different authentication IdPs which is why there are a couple of rules you could use to specify which IdPs to be used for authentication of a specific request from the SP. The rules are structured in a yaml array and are evaluated in the order they are listed in the sso authentication configuration. All rule types could be combined in a rule to achieve the desired differentiation of the SAML requests to the MIRACL Trust SSO in order to choose which IdP to use for authenticating it.

If only method rule is set, it specifies the default method used for authentication by the type and the name of the authentication, structured as type.name. For example, if there is set an OIDC authentication to miracl (the default one) it could be ruled to be the default one by:

authentication:
  rules:
    - method: oidc.miracl

Note that if only one method is listed, it is the default one and it’s not necessary to have authentication rules at all.

parameter rule sets an url parameter which is expected to specify the authentication method of a SAML Request from the SP. For example, if the SSO receives a SAML Request with an url https://<yourssoip>//sso?idp=miracl, it will be authenticated with the authentication method specified for param with key ‘idp’ and value ‘miracl’. In order to authenticate this request specificly by the IdP configured under the name oidc.miracl, the following configuration is required:

authentication:
 rules:
  - parameter:
      key: idp
      value: miracl
    method: oidc.miracl
 oidc:
   miracl:
     client_id: "***"
     client_secret: "***"

header rule sets the name and value of a request header which is expected to specify the authentication method of the SAML Request. For example, if the SSO receives a SAML Request with header ‘X-Forwarded-For’ and value ‘miracl.trust’ and we want it to be authenticated with the OIDC authentication method under the name of miracl, here is how it needs to be configured:

authentication:
 rules:
  - header: 
      key: X-Forwarded-For
      value: miracl.trust
    method: oidc.miracl
 oidc:
   miracl:
     client_id: "***"
     client_secret: "***"

You could configure rules to select the authentication method per user privilegies by specifing a regular expression for the user_id which will be authenticated and/or the name of a defined ldap profile to evaluate. More about configuring ldap and ldap profiles could be read here. In this case the SSO needs to know what is the user_id before evaluating the rule, so additional page to enter it is displayed to the user.

The next example demonstrates how rules could be combined. The user is checked first if he/she could be authorized by the ldap_admins profile. If so, the request is authenticated by saml.myadminidp. If not, the second rule checks if the user_id has a domain miracl.com. If so, the user is authenticated by oidc.miracl. If not, the third rule is evaluated and the user_id is checked for domain gmail.com and evaluated by the ldap_users profile. If both conditions are satisfied, saml.miracl IdP is used. If none of the above are met, oidc.mydefaultidp is applied for any other requests.

authentication:
  rules:
  - ldap: ldap_admins
    method: saml.myadminidp
  - user_id: "^[^@]+@miracl.com$"
    method: oidc.miracl
  - user_id: "^[^@]+@gmail.com$"
    ldap: ldap_users
    method: saml.miracl
  - method: oidc.mydefaultidp
  oidc:
    miracl:
      client_id: "***"
      client_secret: "***"
    mydefaultidp:
      client_id: "***"
      client_secret: "***"
      issuer: "https://myoidcip.com"
  saml:
    myidp:
      entity_id: "entityId"
      idp_metadata_url: "https://myidp.com/metadata"
      certificate: ***
      key: ***
    myadminidp:
      entity_id: "adminEntityId"
      idp_metadata_url: "https://myadminidp.com/metadata"
      certificate: ***
      key: ***
ldap:
  server:
    google:
      method: tls
      serverName: ldap.google.com
      address: ldap.google.com:636
      certificate: |-
        -----BEGIN CERTIFICATE-----
        MIIDbDCCAlSgAwIBAgIGAWkz3Fw1MA0GCSqGSIb3DQEBCwUAMHcxFDASBgNVBAoTC0dvb2dsZSBJ
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        otero2Uksx3F/9g6PtyQx2WRah4A8eA9kQ==
        -----END CERTIFICATE-----
      certificateKey: |-
        -----BEGIN PRIVATE KEY-----
        MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDQ+oPbjugJroh7FavDAR2McYtj
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        HbpMNg17/p8b9Za7IROLV4Ypd7sb
        -----END PRIVATE KEY-----
  query:
    ldap_admins:
      server: google
      search:
      - dn: ou=Users,dc=miracl,dc=com
        filter: "(&(mail={{.UserID}})(memberOf=cn=admins,ou=Groups,dc=miracl,dc=com))"    
    ldap_users:
      server: google
      search:
      - dn: ou=Users,dc=miracl,dc=com
        filter: "(&(mail={{.UserID}})(memberOf=cn=users,ou=Groups,dc=miracl,dc=com))"

Change log level

/etc/miracl-sso/integrations/log.yaml

log:
  level: INFO
  network: tcp
  address: 127.0.0.1:514

Can be set to “EMERGENCY”, “ALERT”, “CRITICAL”, “ERROR”, “WARNING”, “NOTICE”, “INFO” or “DEBUG”.

Note that it should not be set to DEBUG in a production environment.

Service logs can be stored locally or remotely. The above snippet works if there is a log-compatible client set to work on the provided address.

If you just want to change the log level network should be set to ‘local’. For example:

log:
  level: ERROR
  network: local
  address: 127.0.0.1:514

Stats for system performance

/etc/miracl-sso/integrations/stats.yaml

The program uses StatsD to collect usage metrics which can then be used with a StatsD-compatible client such as Graphite to visually render key system performance information such as session starts, logins, communicating with the authentication server, spikes in 404 statuses etc.

An example config would be:

stats:
  prefix: miracl-sso
  network: udp
  address: :8125

Note that prefix defines the prefix that is given to each bucket of stats. Address can be in the format of ‘url:port’ or just ‘port’.

The above example would be suitable for a Graphite installation, as Graphite https://github.com/etsy/statsd/blob/master/docs/graphite.md listens on port 8125 by default. A useful Docker image for Graphite can be found at https://github.com/hopsoft/docker-graphite-statsd.

Session settings

By default the MIRACL Trust SSO server uses internal memory to store its collected logged in sessions. Below is the default config.

/etc/miracl-sso/integrations/memory.yaml

session:
  store:
    memory:
      cleanup_interval: 60

You could specify Redis as an external storage to improve security or share it between multiple SSO server instances. Redis can be used locally or installed on a separate machine. In a production environment, AWS ElastiCache may be used. You could just enable it by including:

/etc/miracl-sso/integrations/redis.yaml

session:
  store:
    redis:
      network: tcp
      address: :6379
      password: ""

The session has a max_age property which specifies the live time of the session in seconds. By default it’s set to be an hour. If you specify its value to 0, the session is deleted after you authenticate to a service, which means that every time a SP would need an authentication, the sso asks you for your PIN so it could authenticate you again. This is helpful if you use different identities for one SP.

session:
  store:
    "max_age": 0