[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] change request: subject attribute designators
Polar, I do agree with you that unique subj-category is the simpliest case. And it was my understanding for some time. We have to decide if the 'itegrated login' that is solved by sun with pam is a requirement that must be met in xacml 1.0. Pam specifically calls out a use case when user must be authenticated with more than one protocol. I would support postponing 'integrated login' till the next version, but in the mean time I wanted to have concrete proposal how to deal with it if we have to. Simon ----- Original Message ----- From: "Polar Humenn" <polar@syr.edu> To: "Simon Godik" <simon@godik.com> Cc: <xacml@lists.oasis-open.org> Sent: Wednesday, October 02, 2002 6:25 AM Subject: Re: [xacml] change request: subject attribute designators > > This is where we get into complex principals that are subject to the > requests. If you allow more than one for the subject category, You end up > with the same problem with subject-category="access-subject", whether you > have it as an Attribute or not, because your designator will return values > for each attribute type requested, and you will not be able to tell > which one they are from. > > I thought, we were saying that for now, i.e. 1.0, there is only one > access-subject, denoted by the subject-category attribute. > > True with the PAM you may have several IDs for a subject based on > different protocols. However, on the target side, when a request is > made, you will generally only have one authentication protocol used, > and therefore only one id for the access-subject. > > Please, let's keep this simple enough to provide acess-control for > simple subjects on simple resources at the target. > > I don't know if this is happed, but I think we should stay with the > model that: > > 1 "subject-category" is an Subject Attribute. > 2. Only one Subject per "subject-category" in the RequestContext. > > However, we can add "authentication-mechanism" as attribute, as > well as "authentication-protocol". Note; the two may be different, > or not implied by one or the other. > > Cheers, > -Polar > > On Tue, 1 Oct 2002, Simon Godik wrote: > > > Xacml request context allows for multiple subjects. Each subject block is identified with the subject-category. > > Subject-category identifies different 'actors': access-subject, codesource, etc. > > > > Category of 'access-subject' is requestor's identity. > > > > There are use cases, such as 'integrated login' where multiple auth mechanisms are integrated. > > Sun solves this with 'pluggable auth module' framework (pam). Pam allows for multiple > > authentication protocols to be configured per application. > > > > This shows that xacml context may contain multiple subject blocks with the same category > > of 'access-subject': separate block per authentication protocol. > > > > Subject blocks are accessed with subject-attribute-designators. > > > > Assumpsion: subject block is uniquely addressed by subject-category > > and authentication protocol. > > > > Proposal. > > Drop DataType attribue of the <xacml-context:AttributeType>. > > > > Extend xacml:subject-attribute-designator with subject-category, and protocol attributes: > > <complexType name SubjectAttributeDesignatorType> > > <attribute name="AttributeId" type="xs:string" use="required"/> > > <attribute name="Issuer" type="xs:anyURI" use="optional"/> > > <attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new > > <attribute name="Protocol" type="xs:anyURI" use="optional"/> <-- new > > </complexType> > > > > example 1.1 - match 'group' attribute of a subject authenticated with kerberos: > > subject-match match-id="string-equal" > > subj-attr-desig attr-id="group" issuer="some-issuer" subj-cat="access-subject" protocol="kerb" > > attr-value admin > > > > example 1.2 - match 'subject-id' attribute of a subject authenticated with kerb: > > subject-match match-id="rfc822Name-match" > > subj-attr-desig attr-id="subject-id" subj-cat="access-subject" protocol="kerb" > > attr-value bart@simpson.com > > > > Note that in example 1.2 subject block is identified by the protocol (kerb), not by the name format. > > > > Simon > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC