Shibboleth Developers

["Scott Cantor" <>]

> - Am I right that for authnContextClassRef I could use i.e.
> "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" as
> value then?

You can use any string you want, mechanically. For correctness, it should be
a class URI, and the DeclRef option should be a declaration URI.

> - Can I also use multiple values like
> authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProte
> ctedTransport,
> 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?

Not with a parameter. If you want something like that, you have to use a
template.

> - For "authnContextComparison" I guess I can use the values "exact",
> "minimum", "maximum", "better", right?

Yes, though it doesn't check them IIRC.

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

You can do anything you want, and the SP software knows nothing about what
any of it means. The IdP is responsible for enforcing what you ask for. I
doubt the beta has any AC support yet, but I don't know for sure.

> - 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"?

Yes.

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

Yes, that's expected. If the AuthnRequest in your POST contains the proper
XML, then the SP is operating as intended.

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

Or an ACL plugin, etc.

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

No. Apache directives are the same as RequestMap properties they map to.

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

That's what I'm saying. You have to trust that the IdP is doing what the
spec says to do, and adding checks for this seems silly to me, not to
mention nearly impossible in the case of AC requirements other than trivial
ones.

>  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

No, unless you're equating authentication at an IdP to an entitlement,
there's nothing similar about the two use cases. Attributes are how you tell
the difference between users with different characteristics. You don't just
assume somebody has access because they authenticated, and if you do, that's
just an implicit attribute, and you still have what amounts to a require
rule (it just turns into require valid-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....).

Doesn't matter, the IdP is the asserting entity. If the IdP doesn't trust
the source of attributes, it shouldn't be using them. The IdP effectively
reflects the sum total of many different people, policies, and components of
the organization it's speaking for.

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

No, any more than the SP cares what attributes you get. People continue to
confuse the ACL layer with the SP, but the SP is not doing authorization,
that layer is doing it. It's included in the software because it's
convenient for people, but I treat it as a separate logical component and it
knows nothing about SAML or anything that goes on during SSO.

You could make it a separate module altogether, unless you want it to
actually poke into the Session Cache entry and do weird stuff. That's the
only reason the API is included, and why the htaccess plugin is just bundled
instead of a separate module.

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

No, you'd just write an ACL plugin or suggest an enhancement to one.
 
> 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>

That would be, again, just an enhancement to the ACL plugin(s), and is not
at all related to what the SP does in processing an assertion. That's the
part I was talking about.

Here's why doing it in the SP logic is pointless: if I issue an
AuthnRequest, remember everything about it, and then reevaluate what I
wanted against the Response, then I could sort of block the session, right?
But what happens if I get an unsolicited Response from the IdP that doesn't
meet my needs? I have no requirements to evaluate, so I have to accept it at
face value, and then it's the application's or ACL plugin's job to decide.

So I think it needs to be the ACL plugin's job, always, not the SP's job.

If you want to have require rules for those fields, or anything else in the
assertion, just suggest them. But they have to be named such that they
hopefully won't collide with any rules people might be using already. I
think require authnContextClassRef and require authnContextDeclRef are
probably reasonable, and consistent with the option names.

-- Scott