Apereo CAS - Managing User Attribute Consent Decisions

Posted by Misagh Moayyed on April 20, 2023 · 6 mins read ·
Content Unavailable
Your browser is blocking content on this website. Please check your browser settings and try again.

Apereo CAS provides the ability to require user consent to attribute release. Practically, this means that before accessing the target application, the user will be presented with a collection of attributes allowed to be released to the application with options to either proceed or deny the release of said attributes.

This tutorial specifically requires and focuses on:

Configuration

User consent decisions and options can of course be managed and stored inside a Redis database. A super modest setup should include the following settings:

cas.consent.redis.host=localhost
cas.consent.redis.port=6379

Consent attribute records stored in the configured repository are signed and encrypted. To handle this correctly, you need to make sure proper signing and encryption keys are defined for consent records:

cas.consent.core.crypto.encryption.key=...
cas.consent.core.crypto.signing.key=...
Note
Remember that such keys must be the same across all CAS nodes, should you want to run CAS in a cluster. On startup, if the settings are left undefined CAS will generate keys for you. You can use the generated keys as a starting point.

With this basic setup, you should start to see CAS prompt users for attribute consent decisions for all applications that intend to receive attributes from CAS.

Management

Attribute consent decisions can be managed using a dedicated attributeConsent actuator endpoint. Once you have turned on and enabled the endpoint, the following operations are possible.

You can obtain and review attribute consent decisions for a user via the following call:

curl -H 'Content-Type:application/json' \
  -X GET https://${host}/cas/actuator/attributeConsent/${username}

Once you have the records, you may decide to remove a decision by its identifier:

curl -H 'Content-Type:application/json' \
  -X DELETE https://${host}/cas/actuator/attributeConsent/${username}/${id}

Or you may decide to remove all decisions for the user:

curl -H 'Content-Type:application/json' \
  -X DELETE https://${host}/cas/actuator/attributeConsent/${username}

Consent decisions can be exported into a zip file:

curl -H 'Content-Type:application/json' \
  -X GET https://${host}/cas/actuator/attributeConsent/export \
  -o consent.zip

The outcome of the request is a binary .zip file that you can choose to store into a consent.zip file. This operation can be handy when if you ever need to switch the backend database to something else. You can export the data into a zip file to a format that CAS can understand later and use to import them back without data loss.

So naturally, there is a parallel operation to import records:

curl -H 'Content-Type:application/json' \
  -X POST https://${host}/cas/actuator/attributeConsent/import \
  -d @path/to/data.json

The data.json should contain the consent record that typically matches the following structure:

{
    "id": "1",
    "principal": "casuser",
    "service": "https://apereo.github.io",
    "createdDate": "2023-04-19T10:59:48.325412",
    "options": "ATTRIBUTE_NAME",
    "reminder": 30,
    "reminderTimeUnit": "DAYS",
    "attributes": "..."
}

As of this writing, there is no bulk import operation. You would need to invoke the above operation multiple times for the number of available records.

Need Help?

If you have questions about the contents and the topic of this blog post, or if you need additional guidance and support, feel free to send us a note and ask about consulting and support services.

So…

I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please feel free to engage and contribute as best as you can.

Happy Coding,

Misagh Moayyed