...
| Expand | ||
|---|---|---|
| ||
The alternative syntax for defining a single rule is just to use a Java Properties file (only the non-XML flat-file syntax is supported, because, obviously...) An example of this was shown earlier. A key point: the name of the file is irrelevant. It doesn't make assumptions about the attribute ID based on the name or allow that property to be omitted. In practice of course it's sensible to name things appropriately for ease of maintenance. The use of Properties files is also handled by the shibboleth.TranscodingRuleLoader bean, which supports vacuuming up a directory tree of Properties file all at once. This is illustrated for you in the conf/attribute-registry.xml file, and by default the conf/attributes/custom/ directory is already designated as a place for these files to be created. You can create any subfolders you want for organization because it will walk the whole tree. You can of course create other loader beans that load different directories if desired. A minor limitation of this approach is that it does not allow the idp.service.attribute.registry.encodeType Spring property to be honored by custom rules. If you want to alter the default for the SAML transcoders' “encodeType” setting, you will need to explicitly set that property in the rule as documented for those transcoders. |
Generic and Required Properties
...
There are a small set of generic properties, some required and some optional. The "Type" refers to the underlying object that the system expects to be able to produce as a value of the property, but String is almost always a supported format to use for convenience.
Name | Req? | Type | Description |
|---|---|---|---|
id | Y | String | The IdPAttribute id/name that is used internally. This dictates when the rule will be applied to attributes within the IdP for outbound encoding, as well as what to call an attribute created during inbound decoding. |
transcoder | Y | Space-delimited list of Bean IDs, or an AttributeTranscoder | This defines which AttributeTranscoder objects should be used to encoder and decode data when the rule runs, and dictates most of the rest of the properties that will be required or supported. In most cases this is expressed by specifying one or more Spring bean IDs in a list; the implementation will turn those into the right objects if they exist. |
activationCondition | Predicate<ProfileRequestContext> or a Bean ID | Standard across the system, this is a condition to evaluate at runtime to control whether to apply the rule | |
encoder | Boolean | Defaults to true, can be set false to limit use of the rule to decoding only | |
decoder | Boolean | Defaults to true, can be set false to limit use of the rule to encoding only | |
relyingParties | Collection<String> or a space-delimited list of Strings | Shortcut for applying an activation condition that matches a set of relying party names against the request | |
displayName[.lang] | String | Language-specific values to use as display names for the IdPAttribute | |
description[.lang] | String | Language-specific values to use as descriptions for the IdPAttribute |
The latter two are optionally language-aware; if the raw property name is used, then the corresponding value is used any time the default Locale is in effect for a request. Otherwise a dot separator must be followed by a language code, which may also include country code.
...
While we advise against doing so, you will run into constrant constant pressure from vendors to support one-off Attribute names. When you agree to do that, you should understand that it won’t stop, and you will end up over time with dozens of these rules to maintain and a brittle configuration prone to problems. Standards exist for that reason.
...