[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cosmos-dev] Scope of Broker Service Group and its implications for 209337
|
Jimmy,
This can be done using the new security model feature in Muse 2.3 but you'll have to wait till the new year :) Basically you can attach an authentication class to the particular capability you are trying to restrict but the requirement is that the "nature of the client" needs to be sent over as part of the WS-Security header.
Balan Subramanian
Autonomic Computing, IBM, RTP, NC
919.543.0197 | bsubram@xxxxxxxxxx
![Inactive hide details for "Mohsin, Jimmy" ---12/11/2007 11:35:22 AM---]()
"Mohsin, Jimmy" ---12/11/2007 11:35:22 AM---
"Mohsin, Jimmy" <Jimmy.Mohsin@xxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
12/11/2007 11:33 AM
Please respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx> |
|
|
All,
As part of 209337, I am defining the scope of Security; and the Encryption of data while it is NOT in transit is outside the scope of most Security Providers.
With that proviso, the ONLY protection we have for securing an MDR is authentication. I was probing to see there was ANY way to use (or perhaps abuse J) Service Groups to aid a 209337 to FURTHER restrict access via enforcing some sort of Authorization; albeit at a very macro level, e.g. by knowing the nature of the client that is trying to access an MDR?
Thanks,
Jimmy Mohsin
Cell +1-609-635-1703
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
