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 reply to OpenID Connect requests to give user identity (through ID Token) and information (through UserInfo endpoint).
As an OP, LL::NG supports many 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
)2.0.12
) - See RFC 9068See 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 allowTip
For example, to allow only users with a strong authentication level:
$authenticationLevel > 2
Each Relying Party has its own configuration way. LL::NG exposes its OpenID Connect metadata to help clients configuration.
Metadata can be downloaded at the standard “Well Known” URL: http://auth.example.com/.well-known/openid-configuration
OIDC metadata example:
{
"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",
"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.
Warning
By default, only standard OpenID Connect claims are exposed to applications. If you want to add non-standard attributes, you have to create a new scope in the Scope values content section and your application must request it.
For each OpenID Connect attribute 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).
By default, the following scope-to-attributes are mapped by LL::NG:
Scope value | Attribute list |
---|---|
profile | name family_name given_name middle_name nickname preferred_username profile picture website gender birthdate zoneinfo locale updated_at |
email email_verified | |
address | street_address locality region postal_code country |
phone | phone_number phone_number_verified |
If you want to expose custom attributes to OpenID Connect clients, you have to declare them in a new scope in this section.
Add your additional scope as Key, and a space-separated list of attributes as Value:
In this example, an OpenID Client requesting for the employment_info
scope will
be able to read the company
and position
attributes from the UserInfo endpoint.
Important
Any attribute defined in this section must be mapped to a LL::NG session variable in Exported Attributes section
Important
Your custom attributes will only be visible if the application requests the corresponding scope value
New in version 2.0.12.
This feature may change in a future version in a way that breaks
compatibility with existing configuration.
By default, LL::NG grants all scopes requested by the application, as long as the user consents to them.
This configuration screen allows you to change that behavior by attaching a rule to a particular scope.
When writing scope rules, you can use the special $requested
variable. This
variables evaluates to true within a scope rule when the corresponding scope
has been requested by the application. You can use this variable in a dynamic
rule when you only want to add a scope when the application requested it.
Examples:
read
: inGroup('readers')
read
scope will be granted if the user is a member of the readers
group even if the application did not request it.write
: $requested and inGroup('writers')
write
scope will be granted if the user is a member of the writers
group, but only if the application requested it.2.0.4
): Set this RP as public
client, so authentication is not needed on tokens endpointsub
). Default value is whatToTrace
.2.0.12
): When
using this option, Access Tokens will use the JWT format, which means they
can be verified by external OAuth2.0 resource servers without using the
Introspection or UserInfo endpoint.2.0.12
): If Access
Tokens are in JWT format, this option lets you release the claims defined
in the Extra Claims section inside the Access Token itself2.0.8
): You can
specify a space-separated list of audiences that will be added to the
ID Token audiences2.0.7
): If this option
is enabled, LL::NG will issue a Refresh Token that can be used
to obtain new access tokens as long as the user session is still
valid2.0.12
): Select
one of the available public key signature algorithms2.0.12
): By default,
UserInfo is returned as a simple JSON object. You can also choose to
return it as a JWT, using one of the available signature algorithms.2.0.4
): A code challenge is
required at Tokens endpoint (see RFC 7636)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
Client Credentials Grant by this client.post_logout_redirect_uri
)When writing your access rules, you can additionally use the following variables:
$_oidc_grant_type
(since version 2.0.14
): the grant type being used to
access this service. Possible values: authorizationcode
,
implicit
, hybrid
, clientcredentials
, password
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.
Changed in version 2.0.12: When using the Choice authentication module, the Choice used for password authentication setting can be used for selecting which authentication choice is used by the Resource Owner Password Credentials Grant. Naturally, the selected choice must be a password-based authentication method (LDAP, DBI, REST, etc.).
See also
Specification for the Resource Owner Password Credentials Grant: RFC 6749#section-4.3
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 attributes will be released on the UserInfo endpoint if they are mapped to Exported Attributes and Extra Claims.
See also
Specification for the Client Credentials Grant: RFC 6749#section-4.4
You can define here macros that will be only evaluated for this service, and not registered in the session of the user.