SP's Login session initiator settings and access control

[Cantor, Scott]

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



>Is there a way I'm missing to "lock down" any of the /Login session initiator settings? By that I mean not be able to override the defaults (say if one set forceAuthn as a default) by directly going to the /Login endpoint with a query string parameter? I.e. what would keep a clueful user from avoiding forceAuthn by just pre-establishing their SP session with /Login?forceAuthn=false ? (Of course, they could do the the same with requested authn context etc.) 

Nothing. The reason being the SP doesn't track its requests, so it wouldn't mean anything if you did, it all has to be checked afterwards. The related reason being that we don't have a setting to block IdP-initiated either.

>Or, as I suspect, if an app really cares, it comes down to the app checking Authn Instant, authn context, etc.?

It has to, so avoiding the false assumption that it can skip that is why they aren't locked.

> Of course, with authnContext, one could add an AccessControl check for that, but is there any form of AccessControl one could do on forceAuthn/Authn Instant?

Not access control, but there's a maxTimeSinceAuthn setting on session creation.

>(For that matter, can the custom SP variables like Shib-Identity-Provider be referenced in AccessControl?  Or only those with a predefined alias like authnContextClassRef?)

Well, you can do just about anything with Apache, but in the SP, no, except that I added the plugin that lets you populate an attribute with, e.g. the entityID from the assertion, which lets you circumvent that restriction. I intended it to be hard/bad to do authorization based on the IdP.

-- Scott