LL::NG can be used as a CAS server. It can allow one to federate LL::NG with:
Another CAS authentication LL::NG provider
Any CAS consumer
LL::NG is compatible with the CAS protocol versions 1.0, 2.0 and part of 3.0 (attributes exchange).
In the Manager, go in
General Parameters »
Issuer modules »
CAS and configure:
Activation: set to
Path: it is recommended to keep the default value (
Use rule: a rule to allow user to use this module, set to
1to always allow.
For example, to allow only users with a strong authentication level:
$authenticationLevel > 2
Configuring the CAS Service¶
Then go in
CAS Service to define:
CAS login: the session key transmitted to CAS client as the main identifier (CAS Principal). This setting can be overridden per-application.
Access control policy: define if access control should be done on CAS service. Three options:
none: no access control. The CAS service will accept non-declared CAS applications and ignore access control rules. This is the default.
error: if user has no access, an error is shown on the portal, the user is not redirected to CAS service
faketicket: if the user has no access, a fake ticket is built, and the user is redirected to CAS service. Then CAS service has to show a correct error when service ticket validation will fail.
Use strict URL matching: (since 2.0.12) enforces a stricter URL matching. By default, LemonLDAP::NG will try to find a declared CAS Application matching the hostname of the requested application if it cannot find a match using the full path. See URL Matching for details
Temporary ticket lifetime: (since 2.0.14): restricts how long Service and Proxy tickets are valid after being generated. For compatibility, the default value of
0means they are valid for the entire session duration. But the CAS spefications recommends
Back-channel logout: (since 2.0.16) enable CAS back-channel logout, which will send SLO requests to CAS applications.
CAS session module name and options: choose a specific module if you do not want to mix CAS sessions and normal sessions (see why).
CAS attributes: list of attributes that will be transmitted by default in the validate response. Keys are the name of attribute in the CAS response, values are the name of session key.
CAS login is not set, it uses
General Parameters »
REMOTE_USER data, which is set to
Configuring CAS Applications¶
If an access control policy other than
none is specified,
applications that want to authenticate users through the CAS protocol
have to be declared before LemonLDAP::NG accepts to issue service
tickets for them.
CAS Applications and then
Add CAS Application. Give a
technical name (no spaces, no special characters), like “app-example”.
You can then access the configuration of this application.
You may add a list of attributes that will be transmitted in the validate response. Keys are the name of attribute in the CAS response, values are the name of session key.
The attributes defined here will completely replace any attributes you
may have declared in the global
CAS Service configuration. In order
to re-use the global configuration, simply set this section to an empty
Service URL: the service (user-facing) URL of the CAS-enabled application. See URL Matching
User attribute: session field that will be used as main identifier.
Logout: enable back-channel logout to this CAS application
Authentication Level: required authentication level to access this application
Access rule: access rule to enforce on this application. If left blank, access will be allowed for everyone.
Comment: set a comment
Name: name to display during logout
If the access control policy is set to
rule will be ignored
You can define here macros that will be only evaluated for this service, and not registered in the session of the user.
Changed in version 2.0.10.
Before version 2.0.10, only the hostname was taken into account, which made it impossible to have two different CAS services behind the same hostname.
Since version 2.0.10, the entire service URL is compared to the Service URL defined in LemonLDAP::NG. The longest prefix wins.
For example, if you declared two applications in LemonLDAP::NG with the following service URLs:
An application located at https://cas.example.com/applications/zone1/myapp will match the first CAS service definition
An application located at https://cas.example.com/undeclared/ will also be accepted in order to preserve the previous behavior of matching on hostnames only.
Changed in version 2.0.12: The Strict URL matching option now lets you decide if LemonLDAP::NG should fall back to legacy host-based matching if it cannot find a declared service matching an incoming service URL. In the previous example, https://cas.example.com/undeclared/ will no longer match if strict URL matching is enabled