ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balan Subramanian <>
Subject RE: [jira] Commented: (MUSE-242) Security model
Date Fri, 21 Dec 2007 16:11:25 GMT

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

Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 |

             12/21/2007 05:10          <>,              
             AM                        <>            
                                       <>, Balan         
                                       RE: [jira] Commented: (MUSE-242)    
                                       Security model                      


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

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


From: Saurabh Dravid []
Sent: Thursday, December 20, 2007 10:13 PM
Cc: Twiner Chris, IT-TBU-DL2-EAI-EDE;; 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                                                    To 
       Please respond to                                                                                       Subject 
                                             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) []
Sent: Wednesday, December 12, 2007 8:35 PM
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) []
Sent: Wednesday, December 05, 2007 9:00 PM
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

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

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:
>             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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message