Attribute Consent -- Restrict by entityId

[Cantor, Scott]

> 3) we can specify which SPs would require attribute-consent and which SPs
> would not require attribute-consent (but that would mean listing all SP's in
> relying-party.xml with individual RelyingPartyByName - which is not ideal as
> many SPs)
> 
> Did I get above right?

I'm fairly certain you are not at all understanding the syntax here, but that doesn't really address your fundamental issue anyway if you're trying to deal with two large, arbitrary sets of SPs.

Defaulting things one way and overriding them another way is one override. Your case (3) doesn't make any sense; you don't specify two lists, you'd specify one. Either you default something on and override it to off, or you default something off, and override it on. Either way it's one override, at least in terms of handling that one specific setting. When you have to deal with more settings, that's a whole different problem.

Nor do you need multiple overrides anyway, not to handle changing one specific setting. You just do one override and apply it to the list of SPs by name (if you're doing it by name). RelyingPartyByName applies to a list of SPs, not one SP.

Having said that, the actual approach used to specify when an override applies (the activation condition) can be very simple or very complex and can be very reasonable or a totally unscaleable mess.

There is, obviously, no "reasonable" strategy to take a set of unbounded, arbitrary, and "sharing no particular characteristic" SPs and magically associate a setting with them. Something has to be done, and that something is likely either ugly, or is handled through a lot of extra infrastructure to delegate out the work.

For example:

1. Brute force list inside relying-party.xml in the override.

Sucks if it's a ton of SPs, but it's potentially reloadable at least.

2. Use RelyingPartyByTag to associate the override with a metadata EntityAttribute extension and then attach the EntityAttribute upstream to the relevant SP metadata, or via a MetadataFilter.

Still sucks, but avoids touching relying-party.xml, might be something you could manage with other tools if you have a full blown metadata management scheme in place, and also opens up more flexibility to address future override needs that might be cross-cutting. That's all discussed in the wiki. This is what I think people should increasingly be looking at.

3. Use a directory or database to manage the rules and then write Java code to access the database at runtime to deduce the setting.

4. Something, something, Grouper. I think some places are using Grouper to attach bits of policy to SPs and then are generating IdP config (or metadata) out of Grouper. That has the advantage of potentially delegating out control over those policy bits to SP owners.

If your problem is identifying 10 SPs, well, doesn't really matter much how you do it. But you can't just magically identify 100 arbitrary SPs from another 100 arbitrary SPs and divide them into two sets. In that case, yes, you have a DefaultRelyingParty, but ultimately you really have two overrides there and you have to somehow classify them into one of the two sets.

-- Scott