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] Potential SAML issues



NISHIMURA Toshihiro wrote:
> 
> Hello,
> 
> Sekhar Vajjhala - Sun Microsystems wrote:
> > ISSUE: saml:Action is a "string"
> >
> >      saml:Action is currently specified as a "string". Making Action
> >      an abstract type  would allow it to be extended. This would allow
> >      the content model to be defined by a schema external to the SAML
> >      spec.
> >
> >      Thus what constitues an action could be determined by the J2SE
> > schema.
> 
> In SAML, saml:Action is used only in saml:Actions and saml:Actions
> have Namespace as an attribute.
> So it is possible to write action(s) such as:
>   <saml:Actions Namespace="urn:J2SEPermission:java.io.FilePermission">
>     <saml:Action>write</saml:Action>
>   </saml:Actions>
> or
>   <saml:Actions Namespace="urn:J2SEPermission">
>     <saml:Action>java.io.FilePermission:write</saml:Action>
>   </saml:Actions>
> 
> But it will be useful if we can write something like:
>   <saml:Action>
>     <J2SEPermission class="java.io.FilePermission">write</J2SEPermission>
>   </saml:Action>

That was the idea ( although the syntax may be different).

> 
> > ISSUE: saml:AuthorizationQuery requires actions.
> >
> >      If actions are optional for XACML, then why should <saml:Actions>
> >      be required in <saml:AuthorizationQuery> ? Both the wording in
> >      the SAML assertions draft as well as the SAML schema place
> >      such a requirement. saml:Actions should be optional in the
> >      AuthorizationQuery to accomodate queries without actions.
> >
> >      At least for now, I don't anticipate this as an issue for J2SE.
> 
> In the latest SAML spec (core-25), AuthorizationDecisionQuery element
> has Resource attribute and Actions element and both of them are
> "required". Does this cause much problems?
> (Resource attribute is "optional" for AuthorizationDecisionStatement
> element.)
> 
> As for J2SE case, I think there is an issue in terminology.
> Sekhar wrote::
> |     A J2SE permission consists of
> |
> |     a. target   ("resource" in XACML terminology )
> |     b. action   (optional)
> (http://lists.oasis-open.org/archives/xacml/200112/msg00045.html)
> 
> In the example of FilePermission, everyone will agreee on that
> "/tmp/*" indicates resources(targets) and "read,write" indicates
> action(s).
> 
> In regard to AWTPermission, the J2SE document says:
> | This is in the same spirit as the RuntimePermission; it's a
> | permission without actions. The targets for this class are:
> |
> | accessClipboard
> | accessEventQueue
> | listenToAllAWTEvents
> | showWindowWithoutWarningBanner
> (http://java.sun.com/j2se/1.4/docs/guide/security/spec/security-spec.doc3.html#20327)
> 
> It says that "accessClipboard" is a target, however, I think it is
> possible to say "accessClipboard" is an action (in XACML terminology).

It is possible but would not be correct.

> 
> > ISSUE: single subject in AuthorizationQuery
> >
> >      saml:AuthorizationQuery currently only contains a single
> >      Subject. While a saml:Subject can support multiple NameIdentifier
> >      or SubjectConfirmation or AssertionSpecifier elements, it
> >      is required that they all belong to the same principal. So
> >      a single subject cannot be used for unrelated principals.
> >
> >      In J2SE, there is a need to base access control on multiple
> >      principals which are not related and this therefore points to
> >      to a need for more than one Subject in the saml:AuthorizationQuery
> >
> >      NOTE: The way out of this appears to be extend
> > SubjectQueryAbstractType.
> 
> Is this the same issue with ISSUE:[DS-11-01:MultipleSubjectAssertions]
> in draft-sstc-saml-issues-06.pdf?

As I understand from the XACML Policy model sub committee meeting
yesterday,
there is already an open issue against what I described above. I did not
check the above issue that you mentioned above.

Sekhar

> 
> Regards,
> Toshi
> ---
> NISHIMURA Toshihiro (FAMILY Given)
> nishimura.toshi@jp.fujitsu.com
> XML Application Technology Dept., PROJECT-A XML, FUJITSU LIMITED

-- 
Sekhar


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


Powered by eList eXpress LLC