ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hawkins, Joel" <>
Subject RE: [jira] Commented: (MUSE-242) Security model
Date Thu, 06 Dec 2007 14:47:33 GMT

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

Also, can you walk us through an example of how this will interact with
subscriptions and (possibly) metric reporting?


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) [] 
Sent: Thursday, December 06, 2007 12:00 AM
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:
>             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:

View raw message