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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

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


Subject: ISSUE POLICY-26 : Security implementation policy should bevalidate-able by schema


Hi folks,

 

The link for this issue in the SCA Policy TC JIRA: http://www.osoa.org/jira/browse/POLICY-26

 

Regards,

Kaanu Joshi

 


From: David Booz [mailto:booz@us.ibm.com]
Sent: Saturday, October 20, 2007 12:47 AM
To: sca-policy@lists.oasis-open.org
Subject: [sca-policy] NEW ISSUE: Security implementation policy should be validate-able by schema

 

TARGET: SCA Policy Framework

DESCRIPTION:

The first issue is on RunAs,

<element name="runAs" type="sca:RunAs"/>
<complexType name="RunAs">
<attribute name="role" type="string" use="required"/>
</complexType>

A runAs element specifies a security role. An alternative setting is to run with the user's identity. There is no way to explicitly specify to use the caller's own identity. The drawback is that when policySet are attached at different levels, it is difficult to explicitly specify using caller's identity if we support policy inheritance.


The other issue is on access control, the schema has

<element name="allow" type="sca:Allow"/>
<complexType name="Allow">
<attribute name="roles" type="string" use="required"/>
</complexType>

<element name="permitAll" type="sca:PermitAll"/>
<complexType name="PermitAll"/>

<element name="denyAll" type="sca:DenyAll"/>
<complexType name="DenyAll"/>

The drawback of the above approach is that the schema doesn't prevent the case that more than one alternative may be specified in the policySet. It is true that there is precedence rule that can be used, i.e., denyAll takes precedence over permitAll, which takes precedence of allow element.


PROPOSAL:

For RunAs and alternative schema is proposed:

<element name securityIdentity type="sca:SecurityIdentity>
<complexType name="SecurityIdentity">
<choice>
<element name="useCallerIdentity" type="sca:UseCallerIdentity" maxOccurs="1"/>
<element name="runAs" type="sca:RunAs"/>
</choice>
</complexType>
<complexType name="UseCallerIdentity"/>
<complexType name="RunAs">
<attribute name="role" type="string" use="required"/>
</complexType>

For access control, the schema could be changed to:

<element name="authorization" type="sca:Authorization"/>
<complexType name="Authorization">
<choice>
<element name="allow" type="sca:Allow" maxOccurs="1"/>
<element name="permitAll" type="sca:PermitAll" maxOccurs="1"/>
<element name="denyAll" type="sca:DenyAll" maxOccurs="1"/>
</choice>
</complexType>



PROVENANCE: SCA-222



Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome



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