Re: [xacml] change request: subject attribute designators

[Polar Humenn <polar@syr.edu>]

Although the client may have several identities due to different
authentication protocols, on the target side, should only have one
client identity associated with the application request because the client
selected only one protocol to authenticate to the target.

Initially people will probably be using XACML to handle access control
decisions on a target side of an application request, CORBA, SOAP, or
otherwise. So, one "access-subject" should be fine. Later, we can still
think of one "access-subject", but it can be a structured subject made up
of multiple principals.

Cheers,
-Polar

On Wed, 2 Oct 2002, Simon Godik wrote:

> 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
> > >
> > >
> >
> >
> >
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>