Soliciting "condition" use cases to document

[Cantor, Scott]

> I need an example where attributes don't get resolved if the user
> authenticated at our LDAP with a certain uid (say "shibguest") and the
> relying party doesn't match a certain entityId.
> 
> I guess I can get the relying party half to work, based on the examples
> already provided in the wiki. But I don't know how to check the uid the
> user entered before resolving the attributes.

The canonical principal name for which attributes are being resolves is in the AttributeResolutionContext's principal member.

The most concise way to do it is probably a Spring expression like:

#profileContext.getSubcontext(
	T(net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext)).principal.equals(''foo")

Using expressions as a predicate is demonstrated in the page with the activation condition examples.

So far I've found that one liner conditions are easiest to do with spring expressions than scripts, but you certainly can do it in a script predicate also.

> (Or I'd have to add a deny rule for each attribute that could be
> resolved. I don't want to do that, because this surely would be
> forgotten when a new attribute is added.)

Well, normally that means your default is the problem. Why don't you just add the RP as an exemption to the policy requirement rule used for your default release rules?

You can certainly also include a filter condition around the user's identity too, though I think that probably requires a script or I guess maybe you could test against an attribute value that contains the user's name.

-- Scott