You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Balan Subramanian (JIRA)" <ji...@apache.org> on 2007/12/06 05:59:43 UTC
[jira] Commented: (MUSE-242) Security model
[ https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a role
Authorization:
Granting access to an identified user or role to do something and access some data
Typically authorization comes after authentication. In Muse, the proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and capability level
For example, consider I have a StockQuote endpoint. Assume only subscribed clients have access to any of the operations in the endpoint. Of subscribed clients, administrators only can access the correctPrice() operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an authorization class (foo) for the endpoint resource type definition in muse.xml and an authentication class (bar) for resource level authentication. In addition, the capability containing the correctPrice() method will have another authentication class (foobar) associated with it.
The key thing to note is that resource level authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an operation invocation
2) There is no provision for establishing a security context
So resource level authentication only serves to allow endpoint builders to aggregate the declaration of authentication class at the resource level instead of at each level. An authentication class specified at this level will not be called by muse if nothing is returned from the security manager for an operation; this would be the case if the operation does not require any security and hence no credentials were provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an admin. When they call the getPrice() Joe's and Jane's credentials (username/password or certificate) will be provided to foo. foo will authenticate them and optionally assign a role to them. bar with authorize the method for them and both will be able to invoke getPrice(). However when they call correctPrice(), foobar will also be called which will allow the invocation only for Jane. The thing to keep in mind though is that Joe and Jane will have to provide their credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired. Similar to the way a persistence class can be assigned to a capability or a resource type we must be able to assign a security class that will handle the actual authentication using mechanisms like JAAS or directly on LDAP or OS password store. The encryption of the credentials also needs to be considered. This will have implications on code generation and client side code as well in addition to the endpoint code itself. This is a better way to provide authentication than using HTTPS and this allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by Ch...@swisscom.com.
Hi Balan,
With regards to changing existing code such as EndpointReference and
MessageHeaders to fit JSR 261 this doesn't seem to make alot of sense.
Indeed it forces Java 1.5 use directly, for us and I suppose many other
slow adopters this is not an option. (don't get me wrong, I'd love to
use 1.5 and a standard api and impl for jsr 261 its just not going to
happen for our requirements).
My position is that WS-Sec is the only sensible standard approach to
security within muse but I recognise that JAAS support would be nice for
some JEE container approaches. Therefore you have two choices,
implement two sets of interfaces to meet those aims and force two sets
of api usage, or use straight DOM like everything else in Muse. Any
other functionality required can be implemented on top of that.
Probably best I give some code examples to make things clearer; in all
cases the Elements processed are soapenv:Envelopes.
SoapClient.addRequestHandler( new ClientRequestHandler(){
public Element processRequest(Element requestEnvelope,
HandlerToken someTokenForProcessing) throws SoapFault {
// overridden inteface function. The token can be used to
decide what kind of information to add
return request;
}
}, token);
given that you can implement a version that uses JAAS callbacks or runs
through wss4j:
SoapClient.addRequestHandler(new JaasHandler(),
subjectInformationToken);
then when SoapClient send is called it can call all registered
RequestHandlers.
Server side:
for the muse.xml root:
<muse xmlns="http://ws.apache.org/muse/descriptor">
<ServerRequestHandler>
<Class>org.apache.etwas</Class>
<Configuration>
....
</Configuration>
</ServerRequestHandler>
for capabilities and resource-type themselves:
<capability>
<capability-uri>...</capability-uri>
<java-capability-class>...</java-capability-class> ...
<security enabled="true">
all tokens present here are passed to the
abstractcapability or the resource directly
</security>
</capability>
then for each ServerRequestHandler:
public interface ServerRequestHandler {
public void configure(Element el, IsolationLayer isoLayer)
throws SomeRelevantException;
public Element processRequest(Element requestEnvelope, Resource
resource) throws SoapFault;
}
In this way each ServerRequestHandler gets loaded by the ResourceRouter.
This implies that the ResourceRouter must now take an envelope instead
of a body (any idea why this is done now?). The ResourceRouter then
passes the request through each of the ServerRequestHandlers.
Resource and Capability have a getSecurityElement function.
This allows ws-sec or jaas based lookups, and anything else thats
interesting to do via handlers.
I hope that makes things a little clearer as to what I mean by not
forcing either of the choices into the core of muse.
cheers,
Chris
PS I really like the idea of an enabled attribute on the
resource/capability items this makes it very easy to disable
functionality.
PPS As a personal choice - with WS-Sec - I would have the security
configuration elements (of the resource) merely contain a cn/ou/dn route
that matches the incoming certificate - or the one pulled from the
truststore.
________________________________
From: Balan Subramanian [mailto:bsubram@us.ibm.com]
Sent: Friday, December 21, 2007 5:11 PM
To: Twiner Chris, IT-TBU-DL2-EAI-EDE
Cc: muse-dev@ws.apache.org; sadravid@in.ibm.com; vinguye2@cisco.com
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi Chris,
You bring up some good suggestions. I think this issue is not restricted
to security alone. One of the issues we have had in integrating Muse on
top of other containers is inconsistency in programming models. For
example, if I were writing something to do with WS-A in some app server
that supports it I would be use EndpointReference class as defined in
the JSR for WS-A. However in Muse we have a different class for
EndpointReference. Now if we want to run Muse on top of that app server
I have to deal with two different endpoint reference classes. I think in
general we shld align with existing JSRs and standards when possible.
I do not see how role based authorization at the capability level can be
accomplished at the message processing layer. Rather than invent our own
interface for Principal or Callback, I think we should use what is
provided as part of the JDK. Callbacks in JAAS can also easily be
extended if your security subsystem uses different mechanisms.
Also it is not clear to me if you are recommending that we not use JAAS
or also if you are recommending that we do not use WS-Security. Kindly
clarify.
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@us.ibm.com
Inactive hide details for ---12/21/2007 05:10:43 AM---Hi,---12/21/2007
05:10:43 AM---Hi,
<Ch...@swisscom.com>
12/21/2007 05:10 AM
To
<sa...@in.ibm.com>, <mu...@ws.apache.org>
cc
<vi...@cisco.com>, Balan Subramanian/Raleigh/IBM@IBMUS
Subject
RE: [jira] Commented: (MUSE-242) Security model
Hi,
I understand the logic, we use wss4j internally for ws-sec, but I don't
see why it must be added to the core of muse as dependencies.
Addtionally whilst JAAS itself may be available it still forces a
heavywieght integration if your model for security does not match the
existing providers.
As both of these approaches (as described in the doc) can easily be
implemented via simple message processing layers I don't see the need to
make them explicit. By all means enable them as optional implementations
but all I ask is that the interface to them doesn't involve jaas etc
callbacks directly. Simply allowing an interface to be registered that
processes the message in SoapClient for sending and an interface
configured in muse.xml for processing the message before it gets sent to
the eprs (isolationlayer?) would allow for more flexibility without the
tight coupling.
cheers,
Chris
________________________________
From: Saurabh Dravid [mailto:sadravid@in.ibm.com]
Sent: Thursday, December 20, 2007 10:13 PM
To: muse-dev@ws.apache.org
Cc: Twiner Chris, IT-TBU-DL2-EAI-EDE; vinguye2@cisco.com; Balan
Subramanian
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
JAAS based authentication and authorization comes with J2SE, so it
should work fine on other non Axis2 environment too. For J2ME
environment JAAS comes as an optional package and most of the programmer
uses Axis2+WSS4J combination for ws-security for their J2ME
applications. Since WSS4J uses Callback handler mechanism on server and
client side to get the user credentials this implies that one have to
install J2ME with JAAS package.
The security model for Muse uses standards for passing credentials
(WS-Security) and JSRs for representing those credentials as java
objects.
We would like to support standards like WS-Security and JSRs like JAAS
because of the fact that Muse might be bundled into other containers
that implement the same.
thanks
With best regards,
Saurabh Dravid,
Staff Software Engineer - Autonomic Computing,
India Software Lab, IBM Software Group
4205 S MIAMI BLVD, DURHAM NC 27703-9141
D148/B500
Phone: +919-254-8783, e-mail: sadravid@in.ibm.com
<ma...@in.ibm.com>
About India Software Lab
<http://w3.ibm.com/articles/workingknowledge/2005/10/ap_isl_main.html>
<Ch...@swisscom.com>
12/12/2007 02:53 PM
Please respond to
muse-dev@ws.apache.org
To
<mu...@ws.apache.org>
cc
Subject
RE: [jira] Commented: (MUSE-242) Security model
Hi,
following on from Vinh, my companies use of muse would benefit from
security (including roles) but implementing JAAS providers to do this is
way too complicated.
Cannot a simple interface for server side, like the approach the rest of
Muse uses, simply supply what getUser() and getRole() actually mean for
a given request? (certificates could, for example, simply provide a DN
for the user name or OU lookup for roles). This could be defined in
muse.xml and implemented by IsolationLayer for example.
For client side the simplest thing should be done, a simple
SecurityHandler callback for SoapClient to pass the underlying Elements
before sending.
JAAS or certificates handling can then easily be added to both client
proxies and the muse isolation layers but won't be forced on any other
environment.
One of the great things about Muse is that it really has a paired down
set of requirements and its easy to extend programming model allows low
cost replacement of many of its features. Using JAAS directly (or even
requiring WSS4J etc) seems to go against this approach.
cheers,
Chris
-----Original Message-----
From: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Sent: Wednesday, December 12, 2007 8:35 PM
To: muse-dev@ws.apache.org
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
Couple comments:
1) Can the design decouple the use of WS-Security and JAAS? Is there
any benefit to doing this?
We currently have WSSE implemented already. On the client side, the
proxies have additional methods to add the WSSE header element, and they
can specify their own WSSE context builder. On the server side, we
customized the SimpleResourceRouter so that we can intercept and
authenticate all requests even before the request is processed, and the
WSSE context builder/extractor can also be specified here. Internally
for authentication, we do use JAAS. But, our design decouples the WSSE
implementation from how the application actually will authenticate the
user, so there is no hard dependency on JAAS.
But if people want to have role-based authorization at the capability
level, I can see why you'd want to use JAAS.
2) Since the proposed design depends on JAAS, will the other non-Axis2
environments work fine, too? For example, OSGI-based deployments?
-Vinh
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Wednesday, December 05, 2007 9:00 PM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and
capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an
operation
invocation
2) There is no provision for establishing a security
context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by Balan Subramanian <bs...@us.ibm.com>.
Hi Chris,
You bring up some good suggestions. I think this issue is not restricted to
security alone. One of the issues we have had in integrating Muse on top of
other containers is inconsistency in programming models. For example, if I
were writing something to do with WS-A in some app server that supports it
I would be use EndpointReference class as defined in the JSR for WS-A.
However in Muse we have a different class for EndpointReference. Now if we
want to run Muse on top of that app server I have to deal with two
different endpoint reference classes. I think in general we shld align with
existing JSRs and standards when possible.
I do not see how role based authorization at the capability level can be
accomplished at the message processing layer. Rather than invent our own
interface for Principal or Callback, I think we should use what is provided
as part of the JDK. Callbacks in JAAS can also easily be extended if your
security subsystem uses different mechanisms.
Also it is not clear to me if you are recommending that we not use JAAS or
also if you are recommending that we do not use WS-Security. Kindly
clarify.
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@us.ibm.com
<Chris.Twiner@swi
sscom.com>
To
12/21/2007 05:10 <sa...@in.ibm.com>,
AM <mu...@ws.apache.org>
cc
<vi...@cisco.com>, Balan
Subramanian/Raleigh/IBM@IBMUS
Subject
RE: [jira] Commented: (MUSE-242)
Security model
Hi,
I understand the logic, we use wss4j internally for ws-sec, but I don't see
why it must be added to the core of muse as dependencies. Addtionally
whilst JAAS itself may be available it still forces a heavywieght
integration if your model for security does not match the existing
providers.
As both of these approaches (as described in the doc) can easily be
implemented via simple message processing layers I don't see the need to
make them explicit. By all means enable them as optional implementations
but all I ask is that the interface to them doesn't involve jaas etc
callbacks directly. Simply allowing an interface to be registered that
processes the message in SoapClient for sending and an interface configured
in muse.xml for processing the message before it gets sent to the eprs
(isolationlayer?) would allow for more flexibility without the tight
coupling.
cheers,
Chris
From: Saurabh Dravid [mailto:sadravid@in.ibm.com]
Sent: Thursday, December 20, 2007 10:13 PM
To: muse-dev@ws.apache.org
Cc: Twiner Chris, IT-TBU-DL2-EAI-EDE; vinguye2@cisco.com; Balan Subramanian
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
JAAS based authentication and authorization comes with J2SE, so it should
work fine on other non Axis2 environment too. For J2ME environment JAAS
comes as an optional package and most of the programmer uses Axis2+WSS4J
combination for ws-security for their J2ME applications. Since WSS4J uses
Callback handler mechanism on server and client side to get the user
credentials this implies that one have to install J2ME with JAAS package.
The security model for Muse uses standards for passing credentials
(WS-Security) and JSRs for representing those credentials as java objects.
We would like to support standards like WS-Security and JSRs like JAAS
because of the fact that Muse might be bundled into other containers that
implement the same.
thanks
With best regards,
Saurabh Dravid,
Staff Software Engineer - Autonomic Computing,
India Software Lab, IBM Software Group
4205 S MIAMI BLVD, DURHAM NC 27703-9141
D148/B500
Phone: +919-254-8783, e-mail: sadravid@in.ibm.com
About India Software Lab
<Ch...@swisscom.com>
12/12/2007 02:53 PM To
<mu...@ws.apache.org>
cc
Please respond to
muse-dev@ws.apache.org Subject
RE: [jira] Commented:
(MUSE-242) Security model
Hi,
following on from Vinh, my companies use of muse would benefit from
security (including roles) but implementing JAAS providers to do this is
way too complicated.
Cannot a simple interface for server side, like the approach the rest of
Muse uses, simply supply what getUser() and getRole() actually mean for
a given request? (certificates could, for example, simply provide a DN
for the user name or OU lookup for roles). This could be defined in
muse.xml and implemented by IsolationLayer for example.
For client side the simplest thing should be done, a simple
SecurityHandler callback for SoapClient to pass the underlying Elements
before sending.
JAAS or certificates handling can then easily be added to both client
proxies and the muse isolation layers but won't be forced on any other
environment.
One of the great things about Muse is that it really has a paired down
set of requirements and its easy to extend programming model allows low
cost replacement of many of its features. Using JAAS directly (or even
requiring WSS4J etc) seems to go against this approach.
cheers,
Chris
-----Original Message-----
From: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Sent: Wednesday, December 12, 2007 8:35 PM
To: muse-dev@ws.apache.org
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
Couple comments:
1) Can the design decouple the use of WS-Security and JAAS? Is there
any benefit to doing this?
We currently have WSSE implemented already. On the client side, the
proxies have additional methods to add the WSSE header element, and they
can specify their own WSSE context builder. On the server side, we
customized the SimpleResourceRouter so that we can intercept and
authenticate all requests even before the request is processed, and the
WSSE context builder/extractor can also be specified here. Internally
for authentication, we do use JAAS. But, our design decouples the WSSE
implementation from how the application actually will authenticate the
user, so there is no hard dependency on JAAS.
But if people want to have role-based authorization at the capability
level, I can see why you'd want to use JAAS.
2) Since the proposed design depends on JAAS, will the other non-Axis2
environments work fine, too? For example, OSGI-based deployments?
-Vinh
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Wednesday, December 05, 2007 9:00 PM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and
capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an operation
invocation
2) There is no provision for establishing a security
context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by Ch...@swisscom.com.
Hi,
I understand the logic, we use wss4j internally for ws-sec, but I don't
see why it must be added to the core of muse as dependencies.
Addtionally whilst JAAS itself may be available it still forces a
heavywieght integration if your model for security does not match the
existing providers.
As both of these approaches (as described in the doc) can easily be
implemented via simple message processing layers I don't see the need to
make them explicit. By all means enable them as optional
implementations but all I ask is that the interface to them doesn't
involve jaas etc callbacks directly. Simply allowing an interface to be
registered that processes the message in SoapClient for sending and an
interface configured in muse.xml for processing the message before it
gets sent to the eprs (isolationlayer?) would allow for more flexibility
without the tight coupling.
cheers,
Chris
________________________________
From: Saurabh Dravid [mailto:sadravid@in.ibm.com]
Sent: Thursday, December 20, 2007 10:13 PM
To: muse-dev@ws.apache.org
Cc: Twiner Chris, IT-TBU-DL2-EAI-EDE; vinguye2@cisco.com; Balan
Subramanian
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
JAAS based authentication and authorization comes with J2SE, so it
should work fine on other non Axis2 environment too. For J2ME
environment JAAS comes as an optional package and most of the programmer
uses Axis2+WSS4J combination for ws-security for their J2ME
applications. Since WSS4J uses Callback handler mechanism on server and
client side to get the user credentials this implies that one have to
install J2ME with JAAS package.
The security model for Muse uses standards for passing credentials
(WS-Security) and JSRs for representing those credentials as java
objects.
We would like to support standards like WS-Security and JSRs like JAAS
because of the fact that Muse might be bundled into other containers
that implement the same.
thanks
With best regards,
Saurabh Dravid,
Staff Software Engineer - Autonomic Computing,
India Software Lab, IBM Software Group
4205 S MIAMI BLVD, DURHAM NC 27703-9141
D148/B500
Phone: +919-254-8783, e-mail: sadravid@in.ibm.com
<ma...@in.ibm.com>
About India Software Lab
<http://w3.ibm.com/articles/workingknowledge/2005/10/ap_isl_main.html>
<Ch...@swisscom.com>
12/12/2007 02:53 PM
Please respond to
muse-dev@ws.apache.org
To
<mu...@ws.apache.org>
cc
Subject
RE: [jira] Commented: (MUSE-242) Security model
Hi,
following on from Vinh, my companies use of muse would benefit from
security (including roles) but implementing JAAS providers to do this is
way too complicated.
Cannot a simple interface for server side, like the approach the rest of
Muse uses, simply supply what getUser() and getRole() actually mean for
a given request? (certificates could, for example, simply provide a DN
for the user name or OU lookup for roles). This could be defined in
muse.xml and implemented by IsolationLayer for example.
For client side the simplest thing should be done, a simple
SecurityHandler callback for SoapClient to pass the underlying Elements
before sending.
JAAS or certificates handling can then easily be added to both client
proxies and the muse isolation layers but won't be forced on any other
environment.
One of the great things about Muse is that it really has a paired down
set of requirements and its easy to extend programming model allows low
cost replacement of many of its features. Using JAAS directly (or even
requiring WSS4J etc) seems to go against this approach.
cheers,
Chris
-----Original Message-----
From: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Sent: Wednesday, December 12, 2007 8:35 PM
To: muse-dev@ws.apache.org
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
Couple comments:
1) Can the design decouple the use of WS-Security and JAAS? Is there
any benefit to doing this?
We currently have WSSE implemented already. On the client side, the
proxies have additional methods to add the WSSE header element, and they
can specify their own WSSE context builder. On the server side, we
customized the SimpleResourceRouter so that we can intercept and
authenticate all requests even before the request is processed, and the
WSSE context builder/extractor can also be specified here. Internally
for authentication, we do use JAAS. But, our design decouples the WSSE
implementation from how the application actually will authenticate the
user, so there is no hard dependency on JAAS.
But if people want to have role-based authorization at the capability
level, I can see why you'd want to use JAAS.
2) Since the proposed design depends on JAAS, will the other non-Axis2
environments work fine, too? For example, OSGI-based deployments?
-Vinh
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Wednesday, December 05, 2007 9:00 PM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and
capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an
operation
invocation
2) There is no provision for establishing a security
context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by Saurabh Dravid <sa...@in.ibm.com>.
Hi,
JAAS based authentication and authorization comes with J2SE, so it should
work fine on other non Axis2 environment too. For J2ME environment JAAS
comes as an optional package and most of the programmer uses Axis2+WSS4J
combination for ws-security for their J2ME applications. Since WSS4J uses
Callback handler mechanism on server and client side to get the user
credentials this implies that one have to install J2ME with JAAS package.
The security model for Muse uses standards for passing credentials
(WS-Security) and JSRs for representing those credentials as java objects.
We would like to support standards like WS-Security and JSRs like JAAS
because of the fact that Muse might be bundled into other containers that
implement the same.
thanks
With best regards,
Saurabh Dravid,
Staff Software Engineer - Autonomic Computing,
India Software Lab, IBM Software Group
4205 S MIAMI BLVD, DURHAM NC 27703-9141
D148/B500
Phone: +919-254-8783, e-mail: sadravid@in.ibm.com
About India Software Lab
<Ch...@swisscom.com>
12/12/2007 02:53 PM
Please respond to
muse-dev@ws.apache.org
To
<mu...@ws.apache.org>
cc
Subject
RE: [jira] Commented: (MUSE-242) Security model
Hi,
following on from Vinh, my companies use of muse would benefit from
security (including roles) but implementing JAAS providers to do this is
way too complicated.
Cannot a simple interface for server side, like the approach the rest of
Muse uses, simply supply what getUser() and getRole() actually mean for
a given request? (certificates could, for example, simply provide a DN
for the user name or OU lookup for roles). This could be defined in
muse.xml and implemented by IsolationLayer for example.
For client side the simplest thing should be done, a simple
SecurityHandler callback for SoapClient to pass the underlying Elements
before sending.
JAAS or certificates handling can then easily be added to both client
proxies and the muse isolation layers but won't be forced on any other
environment.
One of the great things about Muse is that it really has a paired down
set of requirements and its easy to extend programming model allows low
cost replacement of many of its features. Using JAAS directly (or even
requiring WSS4J etc) seems to go against this approach.
cheers,
Chris
-----Original Message-----
From: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Sent: Wednesday, December 12, 2007 8:35 PM
To: muse-dev@ws.apache.org
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
Couple comments:
1) Can the design decouple the use of WS-Security and JAAS? Is there
any benefit to doing this?
We currently have WSSE implemented already. On the client side, the
proxies have additional methods to add the WSSE header element, and they
can specify their own WSSE context builder. On the server side, we
customized the SimpleResourceRouter so that we can intercept and
authenticate all requests even before the request is processed, and the
WSSE context builder/extractor can also be specified here. Internally
for authentication, we do use JAAS. But, our design decouples the WSSE
implementation from how the application actually will authenticate the
user, so there is no hard dependency on JAAS.
But if people want to have role-based authorization at the capability
level, I can see why you'd want to use JAAS.
2) Since the proposed design depends on JAAS, will the other non-Axis2
environments work fine, too? For example, OSGI-based deployments?
-Vinh
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Wednesday, December 05, 2007 9:00 PM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and
capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an operation
invocation
2) There is no provision for establishing a security context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by Ch...@swisscom.com.
Hi,
following on from Vinh, my companies use of muse would benefit from
security (including roles) but implementing JAAS providers to do this is
way too complicated.
Cannot a simple interface for server side, like the approach the rest of
Muse uses, simply supply what getUser() and getRole() actually mean for
a given request? (certificates could, for example, simply provide a DN
for the user name or OU lookup for roles). This could be defined in
muse.xml and implemented by IsolationLayer for example.
For client side the simplest thing should be done, a simple
SecurityHandler callback for SoapClient to pass the underlying Elements
before sending.
JAAS or certificates handling can then easily be added to both client
proxies and the muse isolation layers but won't be forced on any other
environment.
One of the great things about Muse is that it really has a paired down
set of requirements and its easy to extend programming model allows low
cost replacement of many of its features. Using JAAS directly (or even
requiring WSS4J etc) seems to go against this approach.
cheers,
Chris
-----Original Message-----
From: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Sent: Wednesday, December 12, 2007 8:35 PM
To: muse-dev@ws.apache.org
Subject: RE: [jira] Commented: (MUSE-242) Security model
Hi,
Couple comments:
1) Can the design decouple the use of WS-Security and JAAS? Is there
any benefit to doing this?
We currently have WSSE implemented already. On the client side, the
proxies have additional methods to add the WSSE header element, and they
can specify their own WSSE context builder. On the server side, we
customized the SimpleResourceRouter so that we can intercept and
authenticate all requests even before the request is processed, and the
WSSE context builder/extractor can also be specified here. Internally
for authentication, we do use JAAS. But, our design decouples the WSSE
implementation from how the application actually will authenticate the
user, so there is no hard dependency on JAAS.
But if people want to have role-based authorization at the capability
level, I can see why you'd want to use JAAS.
2) Since the proposed design depends on JAAS, will the other non-Axis2
environments work fine, too? For example, OSGI-based deployments?
-Vinh
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Wednesday, December 05, 2007 9:00 PM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an operation
invocation
2) There is no provision for establishing a security context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
Hi,
Couple comments:
1) Can the design decouple the use of WS-Security and JAAS? Is there
any benefit to doing this?
We currently have WSSE implemented already. On the client side, the
proxies have additional methods to add the WSSE header element, and they
can specify their own WSSE context builder. On the server side, we
customized the SimpleResourceRouter so that we can intercept and
authenticate all requests even before the request is processed, and the
WSSE context builder/extractor can also be specified here. Internally
for authentication, we do use JAAS. But, our design decouples the WSSE
implementation from how the application actually will authenticate the
user, so there is no hard dependency on JAAS.
But if people want to have role-based authorization at the capability
level, I can see why you'd want to use JAAS.
2) Since the proposed design depends on JAAS, will the other non-Axis2
environments work fine, too? For example, OSGI-based deployments?
-Vinh
-----Original Message-----
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Wednesday, December 05, 2007 9:00 PM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an operation
invocation
2) There is no provision for establishing a security context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: [jira] Commented: (MUSE-242) Security model
Posted by "Hawkins, Joel" <Jo...@compuware.com>.
Balan,
I think this will be a really nice enhancement. The inclusion of roles
will make the result particularly useful!
Have you given any thought to securing access to properties (or property
sets) as well? It seems like this is something that would fit in nicely
with RMD in terms of specifying roles. IIRC there's already some
security infrastructure in ws.resource.proerties stuff. Look at the
SetResourcePropertiesPermissions interface. It might be a starting
point.
Also, can you walk us through an example of how this will interact with
subscriptions and (possibly) metric reporting?
Thanks,
Joel
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: Balan Subramanian (JIRA) [mailto:jira@apache.org]
Sent: Thursday, December 06, 2007 12:00 AM
To: muse-dev@ws.apache.org
Subject: [jira] Commented: (MUSE-242) Security model
[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel#action_12548919 ]
Balan Subramanian commented on MUSE-242:
----------------------------------------
Here are some more thoughts on the implementation in progress. Any
comments/questions are welcome...
Authentication:
Identifying a user, making sure he is who he says he is and mapping to a
role
Authorization:
Granting access to an identified user or role to do something and access
some data
Typically authorization comes after authentication. In Muse, the
proposal is as follows:
1. Allow authentication at the resource level
2. Allow multi-level authorization at both resource and capability
level
For example, consider I have a StockQuote endpoint. Assume only
subscribed clients have access to any of the operations in the endpoint.
Of subscribed clients, administrators only can access the correctPrice()
operation where any client can access the getPrice() operation.
Using the new security model, the endpoint creator can specify an
authorization class (foo) for the endpoint resource type definition in
muse.xml and an authentication class (bar) for resource level
authentication. In addition, the capability containing the
correctPrice() method will have another authentication class (foobar)
associated with it.
The key thing to note is that resource level
authorization/authentication by themselves do not help because
1) All access to a resource is in the form of an operation
invocation
2) There is no provision for establishing a security context
So resource level authentication only serves to allow endpoint builders
to aggregate the declaration of authentication class at the resource
level instead of at each level. An authentication class specified at
this level will not be called by muse if nothing is returned from the
security manager for an operation; this would be the case if the
operation does not require any security and hence no credentials were
provided by the caller.
Assume Joe and Jane are both subscribed clients and only Jane is an
admin. When they call the getPrice() Joe's and Jane's credentials
(username/password or certificate) will be provided to foo. foo will
authenticate them and optionally assign a role to them. bar with
authorize the method for them and both will be able to invoke
getPrice(). However when they call correctPrice(), foobar will also be
called which will allow the invocation only for Jane. The thing to keep
in mind though is that Joe and Jane will have to provide their
credentials every time.
> Security model
> --------------
>
> Key: MUSE-242
> URL: https://issues.apache.org/jira/browse/MUSE-242
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Routing and Serialization
> Reporter: Balan Subramanian
> Assignee: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: muse-242-design1.0.pdf
>
>
> Muse support for WS-Security for credentials transport is desired.
Similar to the way a persistence class can be assigned to a capability
or a resource type we must be able to assign a security class that will
handle the actual authentication using mechanisms like JAAS or directly
on LDAP or OS password store. The encryption of the credentials also
needs to be considered. This will have implications on code generation
and client side code as well in addition to the endpoint code itself.
This is a better way to provide authentication than using HTTPS and this
allows the granularity of authentication at the capability level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org