[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Is an authentication assertion mandatory in SAML?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC