Specify a default authentication context in Relying Party config

Cantor, Scott cantor.2 at osu.edu
Mon Nov 30 22:00:20 EST 2015


On 11/30/15, 9:52 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:



>Thanks, I see you changed that example.

I just want to be defensive and avoid shortcuts if I'm not sure they're stable.

>Stepping aback, why is it that one sets the Methods and not the Contexts?

SAML 1 and 2 don't represent these things with the same type of data so it's not apples and apples. That was a bug in V2.

The property here returns List<Principal>. The setters are specific to the type of object appropriate to the profile.

> Given that the relying party config is serving in place of the SP sending a RequestedAuthnContext?

That's only true of SAML 2, there isn't any functionality like that in SAML 1, and the objects that have to be compared aren't of the same type.

> Was that just to minimize changes from v2, or some more fundamental reason/"underlying model"?

Every protocol has its own mechanics and terminology. OpenID included, I would imagine. The "engine" underneath doesn't know about any of them, so the comparisons its making have to allow for different kinds of Principal objects to be compared. The only contract is that they be Principal subclasses.

-- Scott



More information about the users mailing list