Configuration of IdP with Delegation extension

[Brent Putman]

On 4/13/12 1:19 PM, Cantor, Scott wrote:
> On 4/13/12 1:02 PM, "Karla Borecky" <kborecky at smith.edu> wrote:
>> This concerned me. How does this affect all of the SPs I am talking to
>> now that *aren't* delegation-aware?


It doesn't.  The way the profile handler is written, if delegation isn't
requested (either by AuthnRequest Audience condition or via metadata
RequestedAttributes) , then the processing is exactly the same as with
the non-delegation profile handler.  The delegation one is just a
subclass of the non-delegation one, so the main processing code is
exactly the same. The delegation subclass just has some Assertion
post-processing code to decorate the Assertion if delegation is
requested (and allowed by policy).  If it's not requested, it's a no-op. 

> I'm not aware that has any effect at all, but I suppose it's just a
> question of not wanting to introduce unneeded code into existing
> transactions.

Exactly.


>  You don't get security by just hiding the fact that the
> second endpoint happens to be there, so it really is just a question of
> comfort level running the subclass for everybody, or not.


Exactly, that is the reason I threw that off-hand comment in the docs
about being able to support both SSO handlers side-by-side.   It doesn't
really make much sense to do it, and it's a PITA b/c you have to hand
out different metadata to different RP's.  But you can if you want to. 
Personally, I wouldn't bother doing that.