[
https://issues.apache.org/jira/browse/MUSE-242?page=com.atlassian.jira.plugin.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]
