...
Expand | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||
EnablementFor most situations, the default behavior of each ProfileConfiguration is appropriate when it comes to what to sign or encrypt. A common use case for creating overrides for particular relying parties is to either turn off XML Encryption, or possibly alter which part of a SAML message is to be signed. This is controlled with a set of properties on all SAMLProfileConfiguration and SAML2ProfileConfiguration objects, each of which is a condition that evaluates to true or false to determine what to sign or encrypt. In most cases, you can set the properties to "true" or "false" to turn them on or off. An example follows: Per-Profile Signing or Encryption Options
For more advanced scenarios, you can configure an arbitrary condition function to control the decision. Most commonly this would be used in conjunction with a built-in condition that works by deciding whether to sign or encrypt based on the security of the underlying communication channel. This isn't typically needed, but an example follows: Conditional Signing or Encryption
Finally, a new feature exists to do encryption "opportunistically", that is, to encrypt whenever possible (meaning a compatible key is found in the peer's metadata to encrypt with) but to skip encryption otherwise. For those wishing to avoid having to constantly adapt their system to deal with new services that don't support encryption, this is an option you can use, understanding that this means a loss of explicit control over whether XML Encryption takes place. This feature is enabled with the idp.encryption.optional property. ConfigurationThere are several levels of SecurityConfiguration objects to control the signing, validation, encryption, and decryption processes. These configurations include things like the keypairs to use, preferred/default algorithms, and algorithm allow or deny lists to enforce. The configurations can be derived from the underlying library defaults, a global IdP default, or a per-profile override. In most cases you will leave the defaults in place, or very occasionally define a special configuration to use for specific profiles and/or relying parties. The default objects that make up these configurations are defined in a system file and are defined to match the defaults in the OpenSAML libraries. You can't modify these beans, but they do document the full range of wiring up of settings that's possible. You can inherit from some of them in order to override specific bits and leave the other defaults in place, which is simpler than creating an entire SecurityConfiguration object from scratch. You can override the default bean name that is used as a global default by setting the idp.security.config property. That effectively ignores the system-defined objects in favor of something else. You can also override this on a per-profile, per-relying-party basis by adding a The (formerly common) case of controlling the use of SHA-1 and SHA-256 digest algorithms while signing is simplified because we have predefined beans that toggle between those two algorithms at a global level, with a property to switch between them (idp.signing.config). Similarly, there are predefined beans for toggling between two data encryption families, AES-CBC and AES-GCM. The former is widespread and well-supported, and vulnerable to attacks that can reveal the data. The latter is not widely supported but is the only practical algorithm that remains secure. A new property will switch between them globally (idp.encryption.config) but in practice that won't work all that well because so many SPs will not support GCM (though that should be considered non-compliant with any modern support for the standard). The following is an example to follow if you need to specify the use of SHA-1 instead of SHA-256 for a specific relying party. Per-Profile Signing Algorithm
Similarly, you can do the same with encryption for GCM: Per-Profile Encryption Algorithm
A more advanced case: to specify a custom keypair for signing for a particular relying party, you might create a bean in credentials.xml called "ObnoxiousVendorCredential", and then do the following (there are many ways to lay things out, this is just an example of what's possible): Per-Profile Credential
Typically you want to think about what you need to customize, and then consolidate definitions of beans as much as possible to simplify the XML. |
...
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Properties defined in idp.properties directly related to this configuration area follow:
|
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
These beans are typically defined internally in various system files for use, or are defined in conf/credentials.xml or conf/relying-party.xml:
The following beans may be defined in conf/global.xml and are, as a result, not reloadable. These lists override library defaults globally and allow updates to these policies in the event of an algorithm compromise or other local constraints.
|
...