Shibboleth Developers

[Lukas Haemmerle <>]

Thanks for your comprehensive answers :) I hope you don't mind if ask
some more questions about points that are not yet completely clear to me
(and probably others as well).

> 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

- Am I right that for authnContextClassRef I could use i.e.
"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" as
value then?
- Can I also use multiple values like
authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport,
urn:oasis:names:tc:SAML:2.0:ac:classes:X509,
urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard" or how is this done?
- For "authnContextComparison" I guess I can use the values "exact",
"minimum", "maximum", "better", right?
- Provided I can use a value like "better", how and where is then the
hierarchical order of AC classes defined (at the IdP?) and can I still
add a custom one?
- Can one use any self defined value as long as it is supported at an
IdP, e.g.
"urn:oasis:names:tc:SAML:2.0:ac:classes:mySuperDuperSecureAuthentication"?


In the RequestMap I tried something like
<
Path
  name="secure"
  authType="shibboleth"
  requireSession="true"
  exportAssertion="true"

authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"

  authnContextComparison="exact">

However, when I acccess /secure with the browser-post binding (which of
course won't the IdP the AC requirements) and
Shib-AuthnContext-Class="urn:oasis:names:tc:SAML:1.0:am:unspecified" I
still get access. From reading your answers below I assume this is
perfectly ok because the the application has to make sure that the
authentication method/class fulfill the requirement.


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

That's useful.


> 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.

I assume the above applies to the Apache directive only.


> 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.

Of course an IdP could lie and it can lie about almost anything it
asserts. But then I wonder whats the point in the whole trust
relationship anyway if you cannot assume that the assertion is correct?
 According to this logic one also could argue that all the SP "require"
rules could be omitted as well because one cannot be sure that the IdP
really sends correct attributes for a user (btw. in this case the SP in
theory can trust the assertion even less because the IdP admin often is
not the same person as the user directory admin who could set false
attributes for a user....).


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

So, basically I can use whatever authnContextClassRef and
authnContextComparison I like (it just used in the authentication
request for saml2 bindings I guess) but the SP doesn't really care about
it at all when it gets the response... ?
Let's assume I want to protect a set of highly sensitive documents with
Apache, so that only x509 authenticated people can access them. And also
let's assume the the IdP is *not* broken. Would I have to implement a
full-fletched application that also handles mime-types and other things
just to serve some pdfs, jpgs, gifs and whatever documents I want to
protect? How would one do that best without writing an extra application
just for making sure the authentication context is the one required?
Won't it be easier to use something like

<Directory /var/www/protected-documents>
               AuthType shibboleth
               ShibRequireSession On
               require Shib-AuthnContext-Class \
urn:oasis:names:tc:SAML:1.0:am:x509
</Directory>

in such a case and if the authentication response doesn't fulfill that
requirement, display an error page that the authentication
method/context requirement was not fulfilled?


Lukas

-- 
SWITCH
Serving Swiss Universities
--------------------------
Lukas Haemmerle, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
,
 http://www.switch.ch