Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Placeholder page for drafting use cases and eventually examples for configuring relying party behavior using dynamic detection of metadata tags.

Signed Assertions vs. Responses

Enabling signed assertions is advisedly handled by turning on WantAssertionsSigned in metadata, but isn't always possible and sometimes has to be combined with disabling signed responses (or just for efficiency).

Disabling Encryption

Setting idp.encryption.optional is usually a workaround for handling the majority of SPs without encryption support, but there are a couple of scenarios in which it's useful to be able to manually disable it. Some federations (InCommon for one) have limitations such that SPs without encryption support are stuck registering keys they don't support. Some SPs support encryption but build in time-bombs by forcing flag day key rotations on all IdPs that cause outages or manual work.

Algorithms

There are metadata extensions that are meant to be used to signal algorithm support, but they're not widely used at this point. The most common scenario is to force SHA-1 for older systems.

Legacy Profiles

A common use case is enabling SAML 1 for legacy systems, often combined with either enabling queries or attribute push (to eliminate the queries).

NameID Format Exceptions

Using <NameIDFormat> elements in metadata (which can also be added at runtime with a filter) is the normal way to trigger them, but the "unspecified" Format has to be triggered with a profile setting. That's not common, but it's easy to define a tag for just in case. The problem is that any two SPs using it are only coincidentally going to want the same data, so this isn't solely a matter of format selection.

Bug Workarounds

Some of the other profile settings are workarounds for bugs, e.g., omitting the NotBefore attribute. Likely not very common but easily tag-driven.

Forcing MFA

Handling SPs that require MFA but can't request it requires IdP-side configuration.

Some of the common interceptor flows tend to be enabled only specific SPs. Attribute consent for one. The authorization checking flow is another case, though the checking condition would probably to be extended for each different service/scenario.

Not relying-party-driven, but a canonical case for using metadata tagging is to drive attribute release, occasionally via bundles a la R&S and also piecemeal. FIltering is ultimately going to perform proportional to the number of policies times their individual overhead, so if tag-based rules are sufficiently fast, a policy per attribute would ultimately match or exceed the approach of defining policies per service.


  • No labels