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?
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?
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:
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 <>
01/22/2009 09:59 AM
To
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:
From: Yang Lei <>
To:
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:
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
