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:
See OpenID Connect service configuration chapter.
Go in General Parameters » Issuer modules » OpenID Connect and configure:
Tip
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",
"PS256",
"PS384",
"PS512"
],
"id_token_signing_alg_values_supported" : [
"none",
"HS256",
"HS384",
"HS512",
"RS256",
"RS384",
"RS512",
"PS256",
"PS384",
"PS512"
],
"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. Set a technical name (without space or special character), like “sample-rp”;
You can then set this RP configuration.
Changed in version In: 2.0.16, all exported attributes are sent if Always send exported attributes option is enabled in OpenID Connect Service. In previous versions, you had to declare them in Options/Scope/Scope Values content too.
For each OpenID Connect attribute you want to expose to applications, you can define:
Attention
The specific sub attribute is not defined here, but in User attribute parameter (see below).
You can define here macros that will be only evaluated for this service, and not registered in the user’s session.
When the Always send exported attributes option is disabled in OpenID Connect Service, attributes can only be released if they are part of a scope.
By default, LL::NG will grant all requested scopes except if Only allow declared scopes option is enabled in OpenID Connect Service.
In this case, 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 that scope.
By default, the following scope-to-attributes are already mapped by LL::NG:
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 Connect client (RP) 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, or if you use a Scope Rule to always enable that scope.
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:
When writing your access rules, you can additionally use the following variables:
The following attributes are made available in the created session:
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.
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.
See also
Specification for the Resource Owner Password Credentials Grant: RFC 6749