{"type":"doc","content":[{"type":"paragraph","content":[{"text":"The IdP includes a very important ","type":"text"},{"text":"feature","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508127"}}]},{"text":" that allows much of the per-SP configuration typically found in ","type":"text"},{"text":"relying-party.xml","type":"text","marks":[{"type":"em"}]},{"text":" or ","type":"text"},{"text":"attribute-filter.xml","type":"text","marks":[{"type":"em"}]},{"text":" 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 ","type":"text"},{"text":"filters","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199507005"}}]},{"text":" supported for adding to federation metadata on the fly.","type":"text"}]},{"type":"paragraph","content":[{"text":"With any of the examples below, there are a couple of different ways one can go about supporting tags for specific use cases. The main one documented by the ","type":"text"},{"text":"MetadataDrivenConfiguration","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508127"}}]},{"text":" topic is the “global” one: altering the profile configuration beans active for a relying party definition to add the “","type":"text"},{"text":".MDDriven","type":"text","marks":[{"type":"code"}]},{"text":"\" suffix automatically wires up support for most of the possible properties in a standard way to allow tag-based control.","type":"text"}]},{"type":"paragraph","content":[{"text":"This is both good and bad. It’s good because it’s simple and a single step for control over a lot of different options. It’s bad because it is somewhat slower due to the need to constantly access the metadata to look up virtually every setting, though the recent releases do this much more efficiently through caching of the decoded tags into a hash table.","type":"text"}]},{"type":"paragraph","content":[{"text":"It’s also something of a risk when remote sources of metadata are used because those sources could in theory slip the same tags into the metadata to influence the behavior of your IdP. This is why you should never trust any remote source other than a federation providing appropriately signed metadata (and NEVER rely on a vendor’s own source of metadata, which are almost always incorrect anyway). Having said that, the ","type":"text"},{"text":"EntityAttributes filter","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199507147"}}]},{"text":" has a means of stripping existing tags from a source before adding back others, so that is an important tool for safety.","type":"text"}]},{"type":"paragraph","content":[{"text":"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.","type":"text"}]},{"type":"extension","attrs":{"layout":"default","extensionType":"com.atlassian.confluence.macro.core","extensionKey":"toc","parameters":{"macroParams":{"minLevel":{"value":"1"},"maxLevel":{"value":"2"}},"macroMetadata":{"macroId":{"value":"930df969b656c0f1423a0b801eaba220"},"schemaVersion":{"value":"1"},"title":"Table of Contents"}},"localId":"5c865f1e-d99d-4225-91e8-d1af241fecca"}},{"type":"heading","attrs":{"level":2},"content":[{"text":"Signing Key Selection","type":"text"}]},{"type":"paragraph","content":[{"text":"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.","type":"text"}]},{"type":"paragraph","content":[{"text":"The goal of this example is to default the system to signing with a particular “current” key/certificate, but tag specific SPs that require the use of a different key or certificate.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Security Configuration Beans","type":"text"}]},{"type":"paragraph","content":[{"text":"Because this has never been a common thing for a Shibboleth IdP to do, there isn’t a clean/simple way to control the key. It’s part of a much larger set of objects that make up the so-called ","type":"text"},{"text":"Security Configuration","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508797"}}]},{"text":" setting, which includes not only keys but also algorithm controls.","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Signing Credentials","type":"text"}]},{"type":"paragraph","content":[{"text":"First you need to actually define beans in ","type":"text"},{"text":"credentials.xml","type":"text","marks":[{"type":"em"}]},{"text":" that load the relevant key and certificate to make up each individual signing credential. In this real world example, the “first” credential has been replaced at some point and in its place two new keys were deployed using properties to locate the files and password. The most important points are that you need to be sure to alias ","type":"text"},{"text":"shibboleth.DefaultSigningCredential","type":"text","marks":[{"type":"strong"}]},{"text":" to the one to use by default, and the ","type":"text"},{"text":"shibboleth.SigningCredentials","type":"text","marks":[{"type":"strong"}]},{"text":" bean needs to reference all of them.","type":"text"}]},{"type":"expand","attrs":{"title":"credentials.xml"},"content":[{"type":"codeBlock","content":[{"text":"\n \n \n\n\n\n\n\n\n","type":"text"}]}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Security Configurations","type":"text"}]},{"type":"paragraph","content":[{"text":"Second, you define a separate security configuration in ","type":"text"},{"text":"relying-party.xml","type":"text","marks":[{"type":"em"}]},{"text":" making use of the non-default key. In this example, several built-in beans are used to simplify the definitions. Only the signing key is overridden.","type":"text"}]},{"type":"expand","attrs":{"title":"relying-party.xml"},"content":[{"type":"codeBlock","content":[{"text":"\n \n \n \n","type":"text"}]}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Adding Tag Support","type":"text"}]},{"type":"paragraph","content":[{"text":"As described in the introduction, you can do this either globally as documented with the ","type":"text"},{"text":".MDDriven","type":"text","marks":[{"type":"code"}]},{"text":" profile bean suffix or just add support for this specific tag:","type":"text"}]},{"type":"expand","attrs":{"title":"relying-party.xml"},"content":[{"type":"codeBlock","content":[{"text":"\n \n","type":"text"}]}]},{"type":"paragraph","content":[{"text":"Of course you would need to do similar overrides of other profiles that make use of the keys.","type":"text"}]},{"type":"paragraph","content":[{"text":"In English, what the strategy bean says is “Look in the metadata for a standardized cross-profile tag named “http://shibboleth.net/ns/profiles/securityConfiguration” whose value is the name of a bean of type ","type":"text"},{"text":"org.opensaml.security.config.SecurityConfiguration","type":"text","marks":[{"type":"link","attrs":{"href":"https://shibboleth.net/cgi-bin/java-opensaml.cgi/org.opensaml.security.config.SecurityConfiguration"}}]},{"text":". In other words, the tag can’t really ","type":"text"},{"text":"be","type":"text","marks":[{"type":"em"}]},{"text":" the configuration in the same way as a boolean or string valued setting but is the name of the bean supplying the configuration.","type":"text"}]},{"type":"heading","attrs":{"level":3},"content":[{"text":"Metadata","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Local Metadata","type":"text"}]},{"type":"paragraph","content":[{"text":"When you control the metadata (or script it, etc.), then you would tag an SP to trigger use of the non-default key like so:","type":"text"}]},{"type":"codeBlock","content":[{"text":"\n \n \n \n my.SecurityConfig.Exception\n \n \n \n \n ...\n \n...\n","type":"text"}]},{"type":"heading","attrs":{"level":4},"content":[{"text":"Remote Metadata","type":"text"}]},{"type":"paragraph","content":[{"text":"For a remote metadata source, you will typically want two filters, one to strip anthing undesired from the feed and another to add the tag you want. In this example, anything other than so-called “entity category” tags are removed before adding the exception tag.","type":"text"}]},{"type":"expand","attrs":{"title":"metadata-providers.xml"},"content":[{"type":"codeBlock","content":[{"text":" \n \n \n \n \n \n\n \n \n my.SecurityConfig.Exception\n \n\n https://paininmybutt.example.org/sp\n ","type":"text"}]}]},{"type":"paragraph"},{"type":"paragraph"}],"version":1}

Browser not supported