Files: conf/idp.properties, conf/intercept/consent-intercept-config.xml, messages/message.properties, views/intercept/attribute-release.vm, views/intercept/terms-of-use.vm
...
Localtabgroup | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||
To allow users to select the attributes they wish to be released, provided the attributes are not being released via a back-channel exchange, you can set the idp.consent.allowPerAttribute property in conf/idp.properties.
When a user rejects consent to attribute release, an
LocalizationThe names and values of attributes displayed during consent may be customized. By default, the locale-aware attribute display name and display value are displayed. Customizing the localization information is generally handled through the rules defined in the AttributeRegistryConfiguration. Selective DisplayBy default, users are prompted to consent to release all attributes unless specifically suppressed on a per-attribute basis. Suppressed attributes are released to relying parties but are not displayed to users. A prompted list, ignored list, and match expressions determine whether consent should be obtained for an attribute based on the attribute ID. To prevent an attribute from being displayed, add the attribute ID to the ignored list or exclude it by a match expression. The ignored list and match expression override the prompted list.
OrderAttributes are, by default, displayed in the natural order of their IDs. Deployers may wish to customize the order in which attributes are displayed to users, in order to present the most relevant or personal attributes first. The order in which attributes are displayed to users may be customized by providing a list of attribute IDs. Attributes not in the list will still be sorted in their natural order, but subsequent to attributes in the list. Define the bean named shibboleth.consent.attribute-release.AttributeDisplayOrder in conf/intercept/consent-intercept-config.xml representing the desired order. The values of the list are attribute IDs. The following example displays the <bean id="shibboleth.consent.attribute-release.CustomAttributeIDComparator" class="org.example.CustomAttributeIDComparator" /> For advanced customization of the attribute display order, a custom Comparator may be provided. Define a bean named shibboleth.consent.attribute-release.AttributeIDComparator in conf/intercept/consent-intercept-config.xml which implements Comparator<String>. For example: <bean id="shibboleth.consent.attribute-release.CustomAttributeIDComparator" class="org.example.CustomAttributeIDComparator" />
Users may choose from three options when deciding the duration of their consent to attribute release. The duration options and descriptive text may be customized via messages/messages.properties.
By default, users are prompted to consent to attribute release if a "new" attribute is released or if an "old" attribute is no longer released. "New" and "old" in this context indicate whether consent has already been given to an attribute ID regardless of the attribute's values. In other words, by default, users are not prompted to consent to attribute release if an attribute's values change. To prompt users to consent to attribute release if the values of an attribute have changed, set idp.consent.compareValues to true in conf/idp.properties Prompting users to consent to attribute release if an attribute's value changes requires additional storage capability, because the hash of an attribute's values must be stored for comparison. If client-side storage without use of HTML Local Storage is used to store consent, comparing attribute values may reduce the number of records that may be stored. Since a consent record is stored for every Service Provider, this may increase how often users are prompted to consent to attribute release |
...
Localtabgroup | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
While the default client-side storage solution is HTML Local Storage, it is possible to use cookies. Because cookies provide limited storage capability, the number of stored consent records is also very limited. By default, for client-side storage via cookies, the maximum number of stored consent records is 10. Depending on the number of attributes released and whether released attribute values are compared, the default limit of 10 may be increased. It is not clear what a reasonable default value should be, but it may be significantly higher. We were conservative with the default. If server-side storage is used, the number of stored consent records should probably be unlimited, represented by a limit of -1 or 0. The maximum number of stored consent records is configured via the idp.consent.maxStoredRecords property in conf/idp.properties
A map is supported to store numbers which refer to attribute IDs in order to reduce the size of consent storage records if desired. The default mapping of attribute IDs to numbers is defined by the shibboleth.consent.DefaultAttributeSymbolics bean, internally to the system. Additional mappings may be added to the shibboleth.consent.AttributeSymbolics bean in conf/intercept/consent-intercept-config.xml
The default lifetime for consent storage records is 1 year, and may be configured via idp.consent.storageRecordLifetime in conf/idp.properties. When consent storage records expire, they will no longer by visible via the storage service. Actual timing of deletion is specific to the storage implementation.
Consent storage records consist of a key and value, like all StorageRecords. The (default) storage key for consent records is a concatenation of the user key and the relying party ID, though this is customizeable. The storage value for consent records is the JSON-serialized form of a Map of Consent objects. A per-user index is maintained in order to expire or limit the number of stored records. Code Block | | js | ||||||||||||||||||||||
collapse | true |
Code Block |
---|
{ "jdoe:https://sp1.example.org":{ "v":"[{\"id\":307},{\"id\":\"mail\"},{\"id\":\"uid\"}]", "x":1479847202110 }, "jdoe:https://sp2.example.org":{ "v":"[{\"id\":307},{\"id\":\"mail\"},{\"id\":\"uid\"}]", "x":1479847206825 }, "jdoe:https://sp3.example.org":{ "v":"[{\"id\":307},{\"id\":\"mail\"},{\"id\":\"uid\",\"appr\":false}]", "x":1479847566214 }, "jdoe:_key_idx":{ "v":"[\"jdoe:https://sp1.example.org\",\"jdoe:https://sp2.example.org\",\"jdoe:https://sp3.example.org\"]" } } |
Auditing
By default, consent audit logs are written to logs/idp-consent-audit.log as defined in conf/logback.xml.
...
Because the attribute release flow has an internal condition attached already, customizing the condition for it requires combining the default activation condition with the custom activation condition. By default, the attribute release flow is not activated if both (1) attributes are not pushed and (2) per attribute consent is enabled.
The terms of use flow does not have a default activation condition.
...
The following example activates the attribute release flow if an attribute is present by combining the default activation condition with a custom condition:
Localtabgroup | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
To combine your own condition with the system default, you would define your bean in, e.g., conf/global.xml:
Then define the property idp.consent.attribute-release.activationCondition to example.AttributeReleaseCondition (your custom bean's ID) to install it and it will be combined with the system's default condition for you. |
Reference
Localtabgroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true |
|
Beans defined, or expected to be defined, in conf/intercept/consent-intercept-config.xml :
Bean ID / Type | Function |
---|---|
shibboleth.consent.terms-of-use.Key | Function which returns the key used to (1) lookup terms of use messages and when concatenated with the user key to (2) lookup storage records, defaults to the relying party ID |
shibboleth.consent.attribute-release.rp.Key 4.1 | Function which returns the key which is concatenated with the user key to lookup storage records, defaults to the relying party ID. Overriding this bean allows a single consent record to cover multiple Relying Parties. |
List of attribute IDs for which consent should be obtained | |
List of attribute IDs for which consent should not be obtained | |
shibboleth.consent.attribute-release.MatchExpression | Regular expression matching the attribute IDs for which consent should be obtained |
shibboleth.consent.attribute-release.AuditFormattingMap | Attribute release audit log format, maps logger name to audit fields |
shibboleth.consent.terms-of-use.AuditFormattingMap | Terms of use audit log format, maps logger name to audit fields |
shibboleth.consent.PreConsentAuditExtractors | Audit fields in addition to the default fields populated at the start of the consent flow |
shibboleth.consent.ConsentAuditExtractors | Audit fields in addition to the default fields used when writing the audit log |
shibboleth.consent.AttributeSymbolics | Limits storage record size by mapping attribute IDs to numbers |
shibboleth.consent.DefaultAttributeSymbolics | Default map that can be used as a parent bean for the bean above to merge in additional values |
shibboleth.consent.AttributeQuery.Condition | Condition that determines whether to apply prior consent decisions in server-side storage to back-channel query requests. Defaults to FALSE. |
Localtab-live | ||||
---|---|---|---|---|
|
Relevant properties defined in conf/idp.properties :
Property | Type | Default | Function |
---|---|---|---|
idp.consent.StorageService | Bean ID | shibboleth.ClientPersistentStorageService | Name of storage service used to store users' consent choices |
idp.consent.userStorageKey | Bean ID | shibboleth.consent.PrincipalConsentStorageKey | DEPRECATED Name of function used to return the String storage key representing a user, defaults to the principal name |
idp.consent.attribute-release.userStorageKey | Bean ID | shibboleth.consent.PrincipalConsentStorageKey | Replacement for "idp.consent.userStorageKey" specific to attribute-release flow |
idp.consent.terms-of-use.userStorageKey | Bean ID | shibboleth.consent.PrincipalConsentStorageKey | Replacement for "idp.consent.userStorageKey" specific to terms-of-use flow |
idp.consent.userStorageKeyAttribute | String | uid | DEPRECATED Attribute whose value is the storage key representing a user, only used when idp.consent.userStorageKey = shibboleth.consent.AttributeConsentStorageKey |
idp.consent.attribute-release.userStorageKeyAttribute | String | uid | Replacement for "idp.consent.userStorageKeyAttribute" specific to attribute-release flow |
idp.consent.terms-of-use.userStorageKeyAttribute | String | uid | Replacement for "idp.consent.userStorageKeyAttribute" specific to terms-of-use flow |
idp.consent.attribute-release.activationCondition 4.1 | Bean ID | shibboleth.Conditions.TRUE | Optional condition to apply to control activation of attribute-release flow along with system default behavior |
idp.consent.terms-of-use.activationCondition 4.1 | Bean ID | shibboleth.Conditions.TRUE | Optional condition to apply to control activation of terms-of-use flow |
idp.consent.allowDoNotRemember | Boolean | true | Whether not remembering/storing consent is allowed |
idp.consent.allowGlobal | Boolean | true | Whether consent to any attribute and to any relying party is allowed |
idp.consent.allowPerAttribute | Boolean | false | Whether per-attribute consent is allowed |
idp.consent.compareValues | Boolean | false | Whether attribute values and terms of use text are stored and compared for equality |
idp.consent.maxStoredRecords | Integer | 10 | Maximum number of records stored when using space-limited storage (e.g. cookies), 0 = no limit |
idp.consent.expandedMaxStoredRecords | Integer | 0 | Maximum number of records stored when using larger/server-side storage, 0 = no limit |
idp.consent.storageRecordLifetime | Duration | P1Y4.0 Infinite4.1+ | Time in milliseconds to expire consent storage records |
Localtab-live |
---|
|
Anchor | ||||
---|---|---|---|---|
|
Relevant messages overridable via messages/messages.properties:
Message | Text |
---|---|
no-release.title | Title of error page displayed when attribute release consent is rejected |
no-release.message | Text of error page displayed when attribute release consent is rejected |
no-terms.title | Title of error page displayed when terms of use consent is rejected |
no-terms.message | Text of error page displayed when terms of use consent is rejected |
V3 Compatibility
An IdP can be upgraded to the current version without any changes, but there are issues around the sorting and hashing of attribute values that may cause unexpected re-prompting for consent even when the actual values of an attribute haven't changed.
...