RE: [security-services] Web SSO <AuthnRequest> conformance

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

Prateek, fair enough.

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Wednesday, October 27, 2004 11:13 AM
To: Thomas Wisniewski; Scott Cantor
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] Web SSO <AuthnRequest> conformance



Thomas,

These estimates are not consistent with our experience. I believe Greg
and Scott's remarks have already spoken to the issue in some depth.

So I would have to say that I do not see a problem or a need to require
additional MTI modes for Browser SSO. The AuthNRequest is an extremely
general structure and I can see that certain specialized deployments may
require many optional fields to be populated. The question is whether
support for such a "rich" AuthNRequest instance should be made MTI.

Other than signatures, I don't see most of these optional fields to be
relevant to most browser SSO use-cases. 
Based on Greg's estimates it seems to me that signatures could also be
accomodated without difficulty.


- prateek

-----Original Message-----
From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com] 
Sent: Tuesday, October 26, 2004 7:31 PM
To: Mishra, Prateek; Scott Cantor
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] Web SSO <AuthnRequest> conformance

That was it exactly. Perhaps the size limits are fairly large (typically
closer to 2k at least), and for conformance (and interop), only "small"
<AuthnRequest>s are handled.

Here's a very trivial request (ids are very short) that is around 800
chars
(base 64 encoding and url encoding will add 33%, and make this around
1150
chars). I guess dig sig is not really required (that would increase size
drastically).

The request can also have SubjectConfirmation, Conditions, AuthContext
stuff, IsPassive, ForceAuthn, AssertionConsumerServiceIndex and URL,
ProviderName, etc... which can hit a 2k limit.


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<samlp:AuthnRequest 
  xmlns="urn:oasis:names:tc:SAML:2.0:protocol" 
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
  Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
  ID="_9494578B5BDA829CF967D5AAA5DFA158C2A85EEF" 
  IssueInstant="2004-10-26T17:56:02Z" 
  Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" 
  NameQualifier="" 
  SPNameQualifier="">
  idp
</saml:Issuer>
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"/>
<samlp:NameIDPolicy 
  AllowCreate="true" 
  Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" 
  SPNameQualifier="sp.company.com"/>
</samlp:AuthnRequest>


Tom.

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Tuesday, October 26, 2004 7:08 PM
To: Scott Cantor; Thomas Wisniewski
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] Web SSO <AuthnRequest> conformance



I am afraid I still don't follow why there is a need for an additional
MTI feature. Is the argument that most AuthNRequest's do not commonly
fit on HTTP URLs? We haven't found this to be the case but then that is
just one opinion.

Maybe I havent understood the real issue in this thread.

- prateek

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, October 26, 2004 6:24 PM
To: 'Thomas Wisniewski'
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] Web SSO <AuthnRequest> conformance

> Seems reasonable. Do you feel it will be added to the conf 
> spec as MUST?

I'd be in favor of making POST MTI, and I think we have to do something.

The ability to do artifact was mostly just a consequence of layering the
spec the way I did (i.e. you get it for free architecturally), but there
wasn't overwhelming interest in using it for anything else.

-- Scott


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/l
eave_workgroup.php.