Note
OpenID Connect is a protocol based on REST, OAuth 2.0 and JOSE stacks. It is described here: http://openid.net/connect/.
LL::NG can act as an OpenID Connect Provider (OP). It will answer to OpenID Connect requests to give user identity (trough ID Token) and information (trough User Info end point).
As an OP, LL::NG supports a lot of OpenID Connect features:
prompt
, display
, ui_locales
, max_age
parameters2.0.4
) - See RFC
76362.0.6
) - See RFC
76622.0.7
)2.0.7
)See OpenID Connect service configuration chapter.
Go in General Parameters
» Issuer modules
» OpenID Connect
and configure:
On
.^/oauth2/
unless you need to use another path1
to always allow.Tip
For example, to allow only users with a strong authentication level:
$authenticationLevel > 2
Each Relying Party has its own configuration way. LL::NG publish its OpenID Connect metadata to ease the configuration of client.
The metadata can be found at the standard “Well Known” URL: http://auth.example.com/.well-known/openid-configuration
An example of its content:
{
"end_session_endpoint" : "http://auth.example.com/oauth2/logout",
"jwks_uri" : "http://auth.example.com/oauth2/jwks",
"token_endpoint_auth_methods_supported" : [
"client_secret_post",
"client_secret_basic"
],
"token_endpoint" : "http://auth.example.com/oauth2/token",
"response_types_supported" : [
"code",
"id_token",
"id_token token",
"code id_token",
"code token",
"code id_token token"
],
"userinfo_signing_alg_values_supported" : [
"none",
"HS256",
"HS384",
"HS512",
"RS256",
"RS384",
"RS512"
],
"id_token_signing_alg_values_supported" : [
"none",
"HS256",
"HS384",
"HS512",
"RS256",
"RS384",
"RS512"
],
"userinfo_endpoint" : "http://auth.example.com/oauth2/userinfo",
"request_uri_parameter_supported" : "true",
"acr_values_supported" : [
"loa-4",
"loa-1",
"loa-3",
"loa-5",
"loa-2"
],
"request_parameter_supported" : "true",
"subject_types_supported" : [
"public"
],
"issuer" : "http://auth.example.com/",
"grant_types_supported" : [
"authorization_code",
"implicit",
"hybrid"
],
"authorization_endpoint" : "http://auth.example.com/oauth2/authorize",
"check_session_iframe" : "http://auth.example.com/oauth2/checksession",
"scopes_supported" : [
"openid",
"profile",
"email",
"address",
"phone"
],
"require_request_uri_registration" : "false",
"registration_endpoint" : "http://auth.example.com/oauth2/register"
}
Go in Manager and click on OpenID Connect Relying Parties
, then
click on Add OpenID Relying Party
. Give a technical label (no
spaces, no special characters), like “sample-rp”;
You can then access to the configuration of this RP.
You can map here the attribute names from the LL::NG session to an OpenID Connect claim.
Claim name | Associated scope | Type | Example of corresponding LDAP attribute |
---|---|---|---|
sub | openid | string | uid |
name | profile | string | cn |
given_name | profile | string | givenName |
family_name | profile | string | sn |
middle_name | profile | string | |
nickname | profile | string | |
preferred_username | profile | string | displayName |
profile | profile | string | labeledURI |
picture | profile | string | |
website | profile | string | |
string | |||
email_verified | boolean | ||
gender | profile | string | |
birthdate | profile | string | |
zoneinfo | profile | string | |
locale | profile | string | preferredLanguage |
phone_number | phone | string | telephoneNumber |
phone_number_verified | phone | boolean | |
updated_at | profile | string | |
formatted | address | string | registeredAddress |
street_address | address | string | street |
locality | address | string | l |
region | address | string | st |
postal_code | address | string | postalCode |
country | address | string | co |
For each OpenID Connect claim you want to release to applications, you can define:
Attention
The specific sub
attribute is not defined here, but
in User attribute parameter (see below).
Attention
By default, only claims that are part of standard OpenID Connect scopes will be sent to a client. If you want to send a claim that is not in the OpenID Connect specification, you need to declare it in the Extra Claims section
If you want to make custom claims visible to OpenID Connect clients, you need to declare them in a scope.
Add your additional scope as the Key, and a space-separated list of claims as the Value:
In this example, an OpenID Client asking for the timelord
scope will
be able to read the rebirth_count
and bloodline
claims from the
Userinfo endpoint.
Danger
Any Claim defined in this section must be mapped to a LemonLDAP::NG session attribute in the Exported Attributes section
Basic
2.0.4
): set this RP as public
client, so authentication is not needed on token endpointAdvanced
sub
)2.0.8
): You can
specify a space-separate list of audiences that will be added the
audiences of the ID Token2.0.7
): If this option
is set, LemonLDAP::NG will issue a Refresh Token that can be used
to obtain new access tokens as long as the user session is still
valid.Timeouts
Security
none
,
HS256
, HS384
, HS512
, RS256
, RS384
, RS512
2.0.4
): a code challenge is
required at token endpoint (see
RFC7636)2.0.7
): After enabling
this feature, an application may request the offline_access
scope, and will obtain a Refresh Token that persists even after
the user has logged off. See
https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
for details. These offline sessions can be administered through
the Session Browser.2.0.8
): Allow the use of the Resource Owner Password Credentials Grant by this client. This feature only works if you have configured a form-based authentication module.2.0.11
): Allow the use of the Resource Owner Password Credentials Grant by this client.Logout
- Allowed redirection addresses for logout: A space separated list of URLs that this client can redirect the user to once the logout is done (through
post_logout_redirect_uri
)- URL: Specify the relying party’s logout URL
- Type: Type of Logout to perform (only Front-Channel is implemented for now)
- Session required: Whether to send the Session ID in the logout request
The Resource Owner Password Credentials Grant allows you to exchange a user’s login and password for an access token. This must be considered a legacy form of authentication, since the Authorization Code web-based flow is prefered for all applications that support it. It can however be useful in some scenarios involving technical accounts that cannot implement a web-based authentication flow.
The Client Credentials Grant allows you to obtain an Access Token using only a Relying Party’s Client ID and Client Secret.
The following attributes are made available in the created session:
_whatToTrace
attribute (main session identifier), is set to the
relying party’s configuration key_scope
attribute is set to the requested scopes_clientId
attribute is set to the Client ID that obtained the access
token._clientConfKey
attribute is set to the LemonLDAP::NG configuration
key for the client that obtained the access token.The Access Rule, if defined, will have access to those variables, as well as the @ENV array. You can use it to restrict the use of this grant to pre-determined scopes, a particular IP address, etc.
These session attribute will be released on the UserInfo endpoint if they are mapped to Exported Attributes and Extra Claims
You can define here macros that will be only evaluated for this service, and not registered in the session of the user.