ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saurabh Dravid <sadra...@in.ibm.com>
Subject RE: [jira] Commented: (MUSE-242) Security model
Date Thu, 20 Dec 2007 21:13:15 GMT
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
Please respond to
muse-dev@ws.apache.org


To
<muse-dev@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



Mime
View raw message