Shibboleth Developers

["Scott Cantor" <>]

> I'm testing the Service Provider 2.0 Beta and was wondering if and how
> one can use authentication context requirements (e.g. this location can
> only be accessed by somebody with
> AuthenticationMethod=urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtec
> tedTransport).

The SP supports a built-in way of specifying a small set of AuthnRequest
options, using RequestMap properties (and by extension Apache commands), or
by passing them as query string parameters to a SessionInitiator for use
with dynamically initiated sessions.

The set of options available via RequestMap is essentially listed in the
configuration schema (see share/xml/shibboleth) under an attributeGroup
called ContentSettings.

Of that set, the following are also now usable on a SessionInitiator
redirect:

entityID        - the IdP to use (providerId also supported for legacy use)
isPassive       - boolean flag
forceAuthn      - boolean flag
authnContextClassRef    - URI of a single AC class
authnContextComparison  - SAML enum constant specifying comparison option

To use them from Apache, you use the new catch-all command
ShibRequestSetting to pass through any RequestMap option:

ShibRequestSetting forceAuthn true

As you can see, this limits you to specifying comparison against a single
context class, which satisfies your question and addresses IMHO most of the
use cases.

If not sufficient for your needs, the SAML2 SessionInitiator can be supplied
with an entire AuthnRequest template in the form of XML inside the
configuration element. You have to hack in a few things to get around the
schema validation process, like a fake ID and an IssueInstant and such, but
everything else in there is optional, so you can just specify stuff you care
about and the rest gets defaulted. So you can put any
RequestedAuthenticationContext element you like in there.

All that said, my approach to this point has been that the SP doesn't
maintain any request state or try to enforce what it sent to the IdP on the
way back in. So if you want to enforce that the IdP did what you wanted
(let's note that it could lie, so what's the point really?), you'd have to
do that yourself in the application, just like now.

In other words, the SP won't detect whether the result matches the request
if the IdP is just broken.

That's a summary of what I would call "application integration of SAML 2.0
SSO functonality with the SP". I spent a lot of time working it out, so be
kind.

Of course, it's not specific to SAML 2.0 since any other protocol could be
supported by supplying a SessionInitiator that knows how to translate those
options into the appropriate request message.
 
> Assuming that this can be done somehow in the RequestMap and/or with a
> special Apache directive, I searched the files a bit found nothing but
> the directives:

I stopped creating an endless set of commands and decided to just wrap them
all in one pseudo command to make it more extensible.

> None of them seems to make sense to use with authentication contexts. (I
> wonder though what the ShibBasicHijack is used for ;) )

That's always been there. It turns AuthType basic into AuthType shibboleth
for cases where hundreds of htaccess files exist.

-- Scott