| Table of Contents | ||||
|---|---|---|---|---|
|
The IdP includes a very important feature that allows much of the per-SP configuration typically found in relying-party.xml or attribute-filter.xml to be offloaded to extension Attribute “tags” in SP metadata. This has a number of advantages, though sometimes this is situational or a matter of preference/style. It can become very unwieldy to maintain long lists of overrides or filter rules, and the performance of the IdP can suffer if the number truly gets out of hand. Metadata is more standardized, can be much more easily scripted when the metadata is not sourced from a federation, and there are a variety of filters supported for adding to federation metadata on the fly.
...
The other option, which will be noted in the examples here, is to wire up by hand specific support for a particular tag doing a specific thing. This isn’t obvious, but it follows a basic pattern and the specific wiring needed is shown in the examples. Note that this doesn’t obviate the risk of specific tags being injected by metadata sources, but in some cases this risk is further mitigated by a lack of benefit in doing so by that source. Some settings just don’t gain somebody anything to manipulate.
| Table of Contents | ||||
|---|---|---|---|---|
|
Signing Key Selection
It is not generally useful practice to use more than one signing key at a time (consider where they’re all stored, and the probability that if one were compromised that the rest would somehow not be?). However, this occasionally becomes necessary either during a transition to a new key, or an adjustment that becomes necessary due to constraints imposed by a particular SP regarding size or changes to security policy, for example, the transition away from SHA-1 certificates though SAML itself isn’t affected by that issue at all when implemented compliantly.
...