Setting up Argus to work with an external OpenID Provider - Implicit Flow#

Defining new OpenID Provider#

To define a new OpenID provider, use the /authentication/v1/openid/provider endpoint:

curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d
    {
        "customer": "mycustomer",
        "shortName": "myprovider",
        "name": "My ADFS Provider",
        "clientID": "argusClient",
        "certificate": "MIIEtjCCAp4CCQDQSsrUHtwMmDANBgkqhkiG9w0BAQUFADAdMRs...",
        "providerURI": "https://my.provider/oidc/authorize",
        "issuer": "https://my.provider",
        "claimsMapping": {
            "userName": "user"
    }
}

In this setup, the claimsMapping specifies to use the claim “user”, which should uniquely identify a user from this provider.
This could be a username, email, user-ID or similar, as long as it is unique, and always returns the same value for the same user.

Note

The certificate should be the same certificate as is defined in well-known OpenID configuration of your provider, which for an ADFS server can be found under https:///.well-known/openid-configuration

The certificate to submit to Argus should be the full base64-encoded JWKS certificate mentioned in the openid-configuration.

Note

The issuer must be the same as the iss claim returned in the id_token.

The issuer should be explicitly stated in https:///.well-known/openid-configuration

If issuer is not set, the issuer will default to expect a prefix of the providerURI.

Note

Some providers do not expose a certificate, instead the JWKS of the provider specifies a set of public key parameters.
Instead of passing a base64-encoded X509 certificate, you can pass an entire base64-encoded JWKS file.

You should find the URL to your providers JWKS file in https:///.well-known/openid-configuration

curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d 
    { 
        ...
        "jwks": "MIIEtjCCAp4CCQDQSsrUHtwMmDANBgkqhkiG9w0BAQUFADAdMRs..."
        ...
    }

Note

When performing authorization of sensitive operations, it is advised to set up the OpenID provider to require the users username/password to verify user presence.
Optionally, user presence may be confirmed without requiring password, depending on the providers OpenID support.

The option authorizationPrompt supports the three following OpenID options:

  • login - require user to enter username and password

  • consent - ask user to confirm without prompting for password

  • none - perform a standard authentication flow, do not require user confirmation

curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d 
    { 
        ...
        "authorizationPrompt": "MIIEtjCCAp4CCQDQSsrUHtwMmDANBgkqhkiG9w0BAQUFADAdMRs..."
        ...
    }

Note

How this behaviour is implemented is up to the provider. Argus cannot control the details of how the provider verifies the user.

Note

Some providers do not support response_type=id_token which is the default flow.

Using the responseType option you can select type token or idTokenAndToken.

However, note that the current implementation requires that the provider redirects back with a valid id_token parameter.

curl -XPOST -H"Argus-API-Key: my/api/key" https://api.mnemonic.no/authentication/v1/openid/provider -d 
{ 
...
"responseType": "token"
...
}