Comparison='minimum' on <samlp:RequestedAuthnContext> (SAML2 SP, binding HTTP-POST)

[Andrea Cividini]

In my SAML2 SP (HTTP-POST Binding) I need to specify "Comparison='minimum'" attribute on my "samlp:RequestedAuthnContext", but every call of "SAML2_AuthnRequest::setRequestedAuthnContext" or every assignment to the attribute "SAML2_AuthnRequest::requestedAuthnContext" just doesn't include this configuration in the value array.

Am I misunderstanding some usage?

[Tom Scavo]

I don't know of ANY implementation that supports anything more than
"exact," which is the SAML default. The use of
samlp:RequestedAuthnContext is still in its infancy, mostly because
that's easiest to implement at the IdP.

Tom

[Andrea Cividini]

I have an example of a working request that I'm attaching it to this thread.
The IdP is a third-party application so I'm just following their technical references.
As you can see in the example we have:

<samlp:RequestedAuthnContext Comparison="minimum">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL2</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>

The 3 levels of possibile AuthContextClassRef:
urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL1
urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL2
urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL3
corresponds to 3 levels of authentication process (SpidL1 => username/password, SpidL2 => username/password/otp, SpidL3 => username/certificate).
The IdP, according to the technical reference, with the 'minimum' value in Comparison can use a higher level of authentication process if required by the context (according to the example, it will require an "authentication context class" of level SpidL2 or higher).

We could omit the attribute, but the features of the Service Provider would be limited.

[Peter Schober]

Not a reply as to how to get the authentication request extended,
but anyway:

* Andrea Cividini <andrea....@globogis.it> [2016-06-17 14:39]:

> As you can see in the example we have:
> <samlp:RequestedAuthnContext Comparison="minimum">
> <saml:AuthnContextClassRef xmlns:saml=
> "urn:oasis:names:tc:SAML:2.0:assertion">
> urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL2</saml:AuthnContextClassRef>
> </samlp:RequestedAuthnContext>
> The 3 levels of possibile AuthContextClassRef:
> urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL1
> urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL2
> urn:oasis:names:tc:SAML:2.0:ac:classes:SpidL3
> corresponds to 3 levels of authentication process (SpidL1 =>
> username/password, SpidL2 => username/password/otp, SpidL3 =>
> username/certificate).

All those values are illegal. You can't just make up your own stuff in
someone elses (esp. OASIS-defined standard) namespace.
Only these values are legal in urn:oasis:names:tc:SAML:2.0:ac:classes:
http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf
-peter

[Marco Ferrante]

> All those values are illegal. You can't just make up your own stuff in

> someone elses (esp. OASIS-defined standard) namespace.

Unfortunately "you" is not the sender of the post: a new Italian law about unified digital identities (a.k.a. SPID) DPCM 24 ottobre 2014 uses these values in technical requirements.

I think OASIS must complain with AgID, the authority which manage technical specifications.

Marco.

[Peter Schober]

Ciao Marco,

* 'Marco Ferrante' via SimpleSAMLphp <simple...@googlegroups.com> [2016-06-20 12:19]:

> > All those values are illegal. You can't just make up your own stuff in
> > someone elses (esp. OASIS-defined standard) namespace.
>
> Unfortunately "you" is not the sender of the post: a new Italian law
> about unified digital identities (a.k.a. SPID) DPCM 24 ottobre 2014
> uses these values in technical requirements.

At
http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/spid
I seem to have found the relevant documents:

http://www.agid.gov.it/sites/default/files/leggi_decreti_direttive/dpcm_24_ottobre_2014a.pdf
While that doesn't reference "urn:oasis" I can find references to
those URI values in the "Regole tecniche":

http://www.agid.gov.it/sites/default/files/circolari/spid-regole_tecniche_v1.pdf
(page 9 seems to define and mandate use of these values).

-peter

[Peter Schober]

* 'Marco Ferrante' <simple...@googlegroups.com> [2016-06-20 12:19]:

> I think OASIS must complain with AgID, the authority which manage
> technical specifications.

I'm not sure that's how things work (i.e., whether OASIS has any
resources or interest to approach people inventing their own
identifiers in OASIS-owned formal namespaces).

For anyone wanting to move this forward in the name of
interoperability maybe a reference to RFC 3121 (esp. the sections on
"Identifier uniqueness considerations" and "Process of identifier
assignment") and one to a statement from the OASIS SSTC will suffice
to get the AgID's attention? As per
https://lists.oasis-open.org/archives/saml-dev/201606/msg00001.html
It might be a while until the next official SSTC meeting, though.
So probably better to start this discussion with AgID ASAP.
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2016-06-20 16:12]:

> For anyone wanting to move this forward in the name of
> interoperability maybe a reference to RFC 3121 (esp. the sections on
> "Identifier uniqueness considerations" and "Process of identifier
> assignment") and one to a statement from the OASIS SSTC will suffice
> to get the AgID's attention? As per
> https://lists.oasis-open.org/archives/saml-dev/201606/msg00001.html
> It might be a while until the next official SSTC meeting, though.
> So probably better to start this discussion with AgID ASAP.

FYI, this has now been added to the SSTC agenda (though the
incorrectness of the assignment seems to be rather obvious even
without a formal statement from the SSTC):
https://lists.oasis-open.org/archives/security-services/201606/msg00002.html
-peter

[Andrea Cividini]

Thank to everybody, I really appreciate your support and attention to all the particulars.

I know it can sound a little radical, but there's no actual way - for me - to interact with AgID since it's the PA company that defines SPID implementation. SPID It's a nation-wide service that is already being used in production contexts, so they will refuse any suggestion or modification request (moreover if you consider that I work for a private company, they will only technically support me with API interaction).

Can we move the AgID discussion to a dedicated thread so we're able get back to the "Comparison='minimum'" problem?
It sounds very strange to me that nobody ever needed to insert the Comaprison attribute in a SAML2 AuthnRequest until now;
considering this piece of code (vendor\simplesamlphp\saml2\

src\SAML2\AuthnRequest.php, Line 721)

if (isset($rac['Comparison']) && $rac['Comparison'] !== SAML2_Const::COMPARISON_EXACT) {
                $e->setAttribute('Comparison', $rac['Comparison']);
            }

I started doing some reverse engeneering on the code and the $requestedAuthnContext attribute usage, and found out that not a single call of 'SAML2_AuthnRequest::setRequestedAuthnContext' or explicit assignment of this property comprends the 'Comparison' key (except for a AuthnRequestTest).
Moreover, the SAML2_Const::COMPARISON_MINIMUM exists but it's never used once.

[Andrea Cividini]

Hello Peter,

I wanted to let you know that AGID published an errata corrige of their technical specification after your support with this issue, which changed the namespaces of those wrong value you warned me about.Thanks a lot.

I must also report that AGID has some further customizations that slightly alter base logic/rules exposed in this document http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf like setting optional attributes to mandatory.
Is this allowed? We communicated them our perplexities about that but they act like they don't want to collaborate.
Thanks a lot again.

Il giorno lunedì 20 giugno 2016 16:40:57 UTC+2, Peter Schober ha scritto:

[Peter Schober]

Hey,

* Andrea Cividini <andrea....@globogis.it> [2016-08-24 11:41]:

> I wanted to let you know that AGID published an errata corrige of their
> technical specification after your support with this issue, which changed
> the namespaces of those wrong value you warned me about.Thanks a lot.

Great!
Maybe that means they're more open even to "outside" (non-gov) feedback?

> I must also report that AGID has some further customizations that slightly
> alter base logic/rules exposed in this document
> http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf
> like setting optional attributes to mandatory.
> Is this allowed? We communicated them our perplexities about that but they
> act like they don't want to collaborate.

You're not providing sufficient (to me) details above but this is not
the right list for generic SAML questions anyway. Please use the OASIS
saml-dev list referenced in previous emails here, which will give you
both faster and much more authoritative answers.

FWIW, I don't think tighenting the requirements from the spec in an
additional profile (which should be formally defined and published for
interop) would be /contradicting/ the profiled spec: If something is
made mandatory in an additional profile any protocol messages adhering
to that additional profile would (by definition) also satisfy the
existing formal SAML specification for a merely optional protocol
element.
This might still run into issues when *implementations* don't support
optional features, of course, so I wouldn't want to comment on that
with any authority, esp not wrt whether doing this is a good idea.

-peter