Valerio Venturi wrote:
Hi, I'm sorry to jump into the exchange so late, but I wasn't able to do it before. I was reading the thread, and everything is pretty smooth until David's March 22th 10:44 mail. At that point, to my understanding, it's not cleat whether there's really a problem with the OASIS profile. What Tom has brought to our attention is that profile would lack the possibility for the IdP that receives a query to determine whether the requester is authorized to get the subjet's attributes. Intially, the problem was stated as proving user presence at the SP, but I think it's more generally an authz problem. User presence it's only a possible policy the IdP may have for authorizing requests. The IdP has to decide whether to allow the request, and each service will have policies for that. I wouldn't suggest doing as I did in the prototype, allowing after the SP's DN, but it's a way. Or, the IdP may issue an authorization decision query to a PDP.
And if you are not careful you end up with recursion, because the PDP needs to pull the user's attributes to see if he is authorised, and this causes the AA which is being pulled from to ask another PDP if the requester if authorised to pull the attributes ... ad infinitum. regards David
I don't see this as a protocol problem. It can become a protocol problem if the protocol doesn't allow to pass all the info needed to the IdP to drive his authorization decision. But I haven't understood why the cert would say much more than the dn for that. Before discussing how to handle a problem with the spec, can you help me understand that?
Valerio
On Sat, 2008-03-22 at 10:31 -0400, Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate. I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************