Balan, I think this will be a really nice enhancement. The inclusion of roles will make the result particularly useful!
Have you given any thought to securing access to properties (or property sets) as well? It seems like this is something that would fit in nicely with RMD in terms of specifying roles. IIRC there's already some security infrastructure in ws.resource.proerties stuff. Look at the SetResourcePropertiesPermissions interface. It might be a starting point. Also, can you walk us through an example of how this will interact with subscriptions and (possibly) metric reporting? Thanks, Joel The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: Balan Subramanian (JIRA) [mailto:[EMAIL PROTECTED] Sent: Thursday, December 06, 2007 12:00 AM 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]
