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:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 8:35 PM To: [email protected] 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:[EMAIL PROTECTED] Sent: Wednesday, December 05, 2007 9:00 PM To: [email protected] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
