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.

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


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.

With best regards,

Saurabh Dravid,
Staff Software Engineer - Autonomic Computing,
India Software Lab, IBM Software Group
4205 S MIAMI BLVD, DURHAM NC 27703-9141
Phone: +919-254-8783, e-mail:
About India Software Lab


12/12/2007 02:53 PM
Please respond to

RE: [jira] Commented: (MUSE-242) Security model


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

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.


-----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

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?


-----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

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...

Identifying a user, making sure he is who he says he is and mapping to a

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

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
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