Re: [saml-dev] Multiple AuthnStatements in Assertion

["Philpott, Robert" <robert.philpott@rsa.com>]

While it may not be done in many (any?) major public SPs today, I am aware of some enterprise deployments (and a government one) that have done it and rely on it. It is certainly something supported in our implementation and it does get used.  That doesn't mean it is justification for including or excluding it. In your case.  I think you should take stock of the target community you are trying to service and anticipate the security requirements of that community.  But I would not just look at today's requirements, but also where you believe they may head over the next few years.  We run across cases regularly where step-up auth is very important.  In some cases they want to support that with federation use cases in addition to local authn and they can't do it if the SAML support is limited.  If that applies to your community, then I'd think twice about forcing restrictions like that.  

Sent from my iPad...
Rob Philpott | EMC Distinguished Engineer | RSA, the Security Division of EMC
Office: 781.515.7115 | Mobile: 617.510.0893


> On Feb 11, 2014, at 8:57 PM, "Cantor, Scott" <cantor.2@osu.edu> wrote:
> 
>> On 2/11/14, 6:39 PM, "Will Hartung" <willh@mirthcorp.com> wrote:
>> 
>> What are some use cases where multiple AuthnStatements are sent, and
>> what are some examples of how Service Providers handle them?
> 
> The only use case I know of is Rob's, and I know of no SPs personally that
> handle it, nor is there any profile that would describe that behavior
> interoperably. OTOH, I know of deployment profiles that explicitly rule
> out multiple statements to avoid the ambiguity. If I was defining the
> profile today, I would push strongly for limiting it.
> 
> -- Scott
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: saml-dev-help@lists.oasis-open.org
> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature