OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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