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 <sadravid@in.ibm.com>,
AM <muse-dev@ws.apache.org>
cc
<vinguye2@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
<Chris.Twiner@swisscom.com>
12/12/2007 02:53 PM To
<muse-dev@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