Soliciting "condition" use cases to document

[Thorsten Michels]

Some months ago Scott Cantor wrote:

 > I'm working on a page of examples [1] for the use of activation
 > conditions in the V3 configuration, and would like to solicit any
 > requests for examples of implementing particularly conditions people
 > would like to implement or have implemented.

 > I started with the basic stuff (relying party-oriented rules). I'll
 > add some examples for how to do booleans, but could use suggestions
 > on what else people think is useful.


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 background is this:
Wenn adding a new SP, the admins of that SP often want to test if 
everything works. If this is an external SP they don't have an account 
on our IdP they could use. I don't want to give them a standard account, 
since that would give them access to other SPs as well.
So I want to give them a special account whose attributes are only 
released to the SP that is being tested.

My first try was to add a filter policy that adds a DenyRule when the 
above conditions are met. But that would require a rule like
<AttributeRule attributeID="*"> <DenyValueRule xsi:type="ANY">
or
<AttributeRule xsi:type="ANY"> <DenyValueRule xsi:type="ANY">
and as far as I can see this is not possible.
(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.)

So now I'm trying to stop creating the attribute values in the first 
place by adding an activation condition to the data resolvers.

I'd be very grateful if you could add an example or if you have a better 
idea to do this.


Thank you very much for your help and for your great work.
Best regards,
Thorsten Michels
University of Kaiserslautern, Germany

-- 
Thorsten Michels
RHRK
TU Kaiserslautern
Postfach 3049
67653 Kaiserslautern
Tel.: 0631/205-2443