sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-j] ISSUE 27 - Security Annotations in generated Component Type -proposal comments
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-j@lists.oasis-open.org
- Date: Fri, 23 Jan 2009 11:34:59 +0000
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>
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
|
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]