Re: Is an authentication assertion mandatory in SAML?

[Marlena Erdos <marlena@us.ibm.com>]

Tim,

>1. The Shibboleth business model requires that an attribute assertion be
communicated by the authentication/attribute authority to the content site
with no accompanying authentication assertion.

Shibb doesn't specifically disallow an authN assertion -- we just don't
need it.  And,
if the user wants to be anonymous, authN assertions are (currently)
problematic.

>2. The received wisdom is that the SAML architecture dictates that there
be an authentication assertion associated with every attribute assertion
("no attribute assertion without authentication assertion").

I seems to me that artifact type 001 requires this rather than the
architecture.
 Given the very good idea of an "artifact framework",
I don't see why this is a requirement -- especially since the Shibb
"artifact" doesn't need it and can
"get the job done".


>3. The received wisdom is that SAML authentication assertions are a record
of an authentication event.

OK.


>However, if we challenge points 2 and 3 above, can we not accommodate the
Shibboleth requirement for attribute assertions without authentication
assertions?

The problem is the use of the  fields inside the assertion for
countermeasure info
rather than in "packaging". Specifically, the requirement to have a short
validity
period is "problematic" at best for an attribute assertion. (The audience
restriction
is also problematic but not as bad.)

By using packaging, you can leave the fields of the assertions in their
"natural state" :-)
and yet get equal counter-measure protections.   The only price you pay is
the need to authenticate and integrity protect the artifact (or POSTed
assertion).
You can do this with PKI, shared secret, Kerberos, etc ...

As far as I can see,   the
main  advantage of the artifact type 0001 is that it doesn't require
an authenticator or integrity check.   The downside is the appropriation
of fields in the assertion for countermeasure checks at the expense of
their intended very useful functions.

Every design has its tradeoffs.

I'm willing to have two designs, each with their own advantages
and disadvantages.

I happen to think that there are a lot of environments that won't
have a problem with authenticating and integrity-protecting either
an artifact or POSTed assertion.   For these environments, putting
impersonation countermeasure info in "packaging" is the better choice.
For other environments, the current type 0001 artifact is preferable.

Thanks,
Marlena