SAML2 SSO: AuthnContext Class Schemas: "PasswordProtectedTransport" vs "unspecified"

Question

BACKGROUND:

My company is acting as the Service Provider to our clients that are the IDP. We use OpenAM, but our clients use ADFS or Shibboleth. We exchange metadata files for establishing federations, not URLS. A client asked why we require an AuthnContext class schema (specifically PasswordProtectedTransport), and not only do we not know why, we don't know how to change it or what that would mean.

QUESTION:

What is the functional difference between using "PasswordProtectedTransport" vs "unspecified" for the AuthnContextClassRef in a SAML2 assertion?

We currently use PasswordProtectedTransport amongst all our clients, but no one at my company can tell me why we require this. If we remove it, the federation stops working with a 500 error and a "NoAuthnContext" in the SAML trace. We also don't understand that, as I was led to believe from SAML documentation that having a schema is optional for the authentication. Even so, I saw no explanation anywhere of what the implications of using "unspecified" would be.

I can’t find any thorough explanation or discussion anywhere about this topic and was hoping someone could elaborate for me, as I am struggling to find light on this.

Answer 1

RequestedAuthnContext in a request is a mean for a SP to ask the IDP to authenticate the user with a specific authentication mechanism.
For example, if you specify PasswordProtectedTransport in your request, the IDP knows it has to authenticate the user through login/password, protected by SSL/TLS.
The IDP says in its response which mechanism it used to authenticate the user through AuthnContextClassRef.

RequestedAuthnContext in a request is optional, but AuthnContextClassRef in the assertion is mandatory as specified by the SAML schema (hence the 500 error you encountered).
Basically, the unspecified URN is used by the IDP to say "I don't want to tell you how I identified the user".
As a SP, you have the choice to accept that answer or reject it, if you want to ensure that the user is authenticated with a secure mechanism.