Re: [xacml] change request: subject attribute designators

[Simon Godik <simon@godik.com>]

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
> >
> >
>
>
>
>