# documentation:2.0:idpcas
Keywords: documentation,2.0,idpcas

# CAS server

## Presentation

LL::NG can act as an CAS server, that can allow one to federate LL::NG with:

- Another LL::NG system configured with CAS authentication
- Any CAS consumer

LL::NG is compatible with the CAS protocol versions 1.0, 2.0 and part of 3.0 (attributes exchange).

## Configuration

In the Manager, go in `General Parameters` » `Issuer modules` » `CAS` and configure:

- Activation: set to `On`.
- Path: keep `^/cas/` unless you have change Apache portal configuration file.
- Use rule: a rule to allow user to use this module, set to 1 to always allow.

For example, to allow only users with a strong authentication level:

    $authenticationLevel > 2

Rewrite rules must have been activated in Apache portal configuration or in Nginx portal configuration.

Then go in `Options` to define:

- CAS login: the session key used to fill user login (value will be transmitted to CAS clients).
- CAS attributes: list of attributes that will be transmitted in validate response. Keys are the name of attribute in the CAS response, values are the name of session key.
- Access control policy: define if access control should be done on CAS service. Three options:
  - none: no access control, the server will answer without checking if the user is authorized for the service (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.
- CAS session module name and options: choose a specific module if you do not want to mix CAS sessions and normal sessions (see why).

If `CAS login` is not set, it uses `General Parameters` » `Logs` » `REMOTE_USER` data, which is set to `uid` by default