Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type -proposal comments

[Yang Lei <yanglei@us.ibm.com>]

Thanks Mike.

comments.

Regards,

Yang Lei

WebSphere SCA Feature Pack Development -- SCA Architect
Phone: (919) 543 8887 T/L 441-8887
e-mail: yanglei@us.ibm.com

SCA Feature Pack: http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
RTP Technical Vitality: http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
WebSphere Lab Advocate for Royal Bank of Scotland


Mike Edwards <mike_edwards@uk.ibm.com>

Mike Edwards <mike_edwards@uk.ibm.com>

01/23/2009 06:34 AM

To	sca-j@lists.oasis-open.org
cc
Subject	Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments

Yang Lei,

More comments inline

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com

From:	Yang Lei <yanglei@us.ibm.com>
To:	Mike Edwards/UK/IBM@IBMGB
Cc:	sca-j@lists.oasis-open.org
Date:	22/01/2009 16:02
Subject:	Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments

---

Hello Mike,

Thank you for the comments. I would like to discuss more on the comment to 2. I used the current sample in 10.6.2.1 to create the following componentType. Can you let me know what you think of the follow questions?

1. If there is no operation under implementation any more, the componentType will not contain the method level policySet? 
<mje> 
Policy TC removed the <operation/> elements from the SCA schema in October.  These <operation/> elements never supported metadata about individual parameters anyway - which is one of the reasons they were eventually removed. 

My suggestion is that any Policy annotations (intents or policy sets) for methods or for method parameters should be placed into the Java interface class BY THE DEVELOPER. 
The reason for this approach is that the Java interface class IS represented in the componentType: 

<componentType...> 
    <component...> 
        <implementation.java.../> 
        <service....> 
            <interface.java interface="foo.bar.myInterface"/>    <=== here it is !!
       </service> 
    </component> 
</componentType> 

So this means that any of the annotations applied to methods and/or parameters of the interface are present in the componentType metadata. 
</mje>
2. As componentType does not have the section of policySet, where the policySet definition should be? Does it mean we generate both componentType and the definitions,xml? What the naming convention should be for the generated policySets?
<mje> 
Not sure I follow this. 
PolicySets are declared in <definitions/> 
<definitions/> can be separately contributed to the SCA Domain. 

So if the developer or the assembler wants to use the Policy Sets that you declare below they must 
be declared somewhere - either in the contribution containing this application or in a separate 
"system wide" contribution (eg done by the company security experts). 

I suspect that one issue here is that you have identified the case of some "SCA specification defined" 
PolicySets in the case of the "permitAll" Policy Set. 

If there are "special case" Policy Sets of this kind, then perhaps we should update the Policy spec 
to say that a) these policy sets are defined normatively by the SCA Policy spec    and b) they are always 
present in any SCA runtime and do not have to be contributed to the Domain. 
</mje>
< YL Defining system wide policySet approach works for the annotation of permitAll and denyAll , as they do not have parameters. How will you define the policySet for  @RunAs, @RolesAllowed that accept parameter?.../>

The following snippet shows the component type for the above component implementation fragment that maps the implementation security annotation of @RolesAllowed, @RunAs, @PermitAll.

<?xml version="1.0" encoding="ASCII"?> 
<componentType xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200712"> 
<implementation.java class="services.account.AccountServiceImp" policySets="allow_customer, runas_accountants">
<operation name="getAccountReport" service="AccountService" policySets="allow_customer, allow_accountants" />
<operation name="fromUSDollarToCurrency" service="AccountService" policySets="permitAll" />
</implementation>
</componentType>

The following is what the policySet definition looks like for this case.

<policySet name="allow_customers">
<authorization>
<allow roles="customers">
</authorization>
</policySet>

<policySet name="allow_accountants">
<authorization>
<allow roles="accountants">
</authorization>
</policySet>

<policySet name="permitAll">
<authorization>
<permitAll/>
</authorization>
</policySet>

<policySet name="runas_accountants">
<securityIdentity>
<runAs role="accountants">
</securityIdentity>
</policySet>


Here is the snippet of the sample

@RolesAllowed(“customers”)

@RunAs(“accountants” )

public class AccountServiceImpl implements AccountService {

...

@RolesAllowed({“customers”, “accountants”})

public AccountReport getAccountReport(String customerID) {

...

}

@PermitAll

public float fromUSDollarToCurrency(float value) {

...

}

}

Regards,

Yang Lei

WebSphere SCA Feature Pack Development -- SCA Architect
Phone: (919) 543 8887 T/L 441-8887
e-mail: yanglei@us.ibm.com

SCA Feature Pack: http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
RTP Technical Vitality: http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
WebSphere Lab Advocate for Royal Bank of Scotland


Mike Edwards <mike_edwards@uk.ibm.com>

Mike Edwards <mike_edwards@uk.ibm.com>

01/22/2009 09:59 AM

To	sca-j@lists.oasis-open.org
cc
Subject	Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal comments

Yang Lei,

Thanks for producing this proposal. In general it looks very good.

Some comments inline as <mje>...</mje>

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com

From:	Yang Lei <yanglei@us.ibm.com>
To:	sca-j@lists.oasis-open.org
Date:	21/01/2009 22:16
Subject:	[sca-j] ISSUE 27 - Security Annotations in generated Component Type - proposal

---

Here is the proposal for issue 27: http://www.osoa.org/jira/browse/JAVA-27. 

The highlights of the proposal:

1. Instead of defining SCA security implementation policy annotations, point to JSR 250 security annotations 
<mje> 
I'm OK with this proposal. 

I think that there is a need to spell out the mapping of the annotations to the intents declared by the 
Policy spec. It may seem obvious, but to be normative, you have to state it explicitly. 

This should be in 10.6.2 I think. 
</mje>

2. Not generating componentTypes for the above annotations, due to two major reasons:

• some of the annotations can apply onto the methods level, while component type definition does not have operational level any more.
• if we did generate the information into component type, we also need to generate the policysets to apply the policy...

<mje> 
I don't agree with this. If they dont turn up in the componentType, then in effect they are useless - or else you are proposing 
a second mechanism for transmitting information from the implementation to the using <component/> 

Any annotations on method or class level MUST turn up in the component type. 

Annotations below the method level MUST be placed on the interface class. The annotations then turn up in the componentType 
as part of the interface declaration in the componentType. 

I think that this approach works... 
</mje> 

3. Also added are the other annotations that is missing from section 8, related to 10.3 Application intent annotations: 

@Authentication
@Confidentiality
@Integrity
@Intent
@PolicySets
@Qualifier
@Requires

All the changes are under 8.2, 8.5, 8.15, 8.19, 8.22, 8.25, 10.6.2, 10.6.2.1. 
<mje>excellent</mje>

(See attached file: sca-javacaa-1.1-spec-cd01-rev4a-Issue27.doc)(See attached file: sca-javacaa-1.1-spec-cd01-rev4a-Issue27.pdf)


Thanks Dave for the review and comments earlier.

Regards,

Yang Lei

WebSphere SCA Feature Pack Development -- SCA Architect
Phone: (919) 543 8887 T/L 441-8887
e-mail: yanglei@us.ibm.com

SCA Feature Pack: http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
RTP Technical Vitality: http://swgcomm.bluehost.ibm.com/siteFiles/labs.html?location=SEUS&type=cluster
WebSphere Lab Advocate for Royal Bank of Scotland
[attachment "sca-javacaa-1.1-spec-cd01-rev4a-Issue27.doc" deleted by Mike Edwards/UK/IBM] [attachment "sca-javacaa-1.1-spec-cd01-rev4a-Issue27.pdf" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[attachment "pic10692.gif" deleted by Mike Edwards/UK/IBM]

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU