Dear all, Apologies for the long mail, but there seemed to be no reasonable way of splitting this up.
I'm working in a project where we will use ServiceMix (base: v3.0) as a router connecting several Web services (SOAP1.1 with attachments) and for providing commonly needed services, such as user and group management, authentication, authorization, XML-based data persistence, and others. In this project we will develop a number of extensions to/components, which - if there is interest - we might donate to the SM project, as well. Last week I was investigating SM security (for results: see http://goopen.org/confluence/pages/createpage.action?spaceKey=SM&title=S ecurity&linkCreation=true&fromPageId=13484 in the confluence; hasn't been activated yet) My findings suggest the following: - Authorization has to be done at the first endpoint where the normalized message (NM) appears - The SecuredBroker performs allows access based on the belonging of the normalized message's subject's roles. The permissions of the roles are given via the AuthorizationMap. The SecuredBroker DOES NOT check which service provided the original message. In our project, we have a setup where one and the same user may have different permissions depending on which service he's utilizing. Given that my findings are correct and that SM doesn't yet provide this function, I'd like to extend the authorization to include the originating service. (cp. JAAS authorization where a policy defines permissions based on codebase and Principal) Requirements: - *Authentication of calling service*: the consumer service starting a flow of messages (i.e. the one where the NM appears in the ESB) needs to be authenticated. - *Authentication of calling user*, the user using the calling service. Implementation: e.g. user tags in WS-Security. *Every service invocation needs to both authenticate user and service.* - *Client side permission specification* Client services need to be able to change permissions via service invocation. Hence, expanding the AuthorizationMap mechanism doesn't seem feasible. Ideas for implementation/realization: - *In general*: A new Broker as subclass of DefaultBroker/SecuredBroker authorizing based on calling service - *Authentication of calling service*: - For servicemix-http/external consumers: signing SOAP messages. - "ESB-internal" endpoints which are assumed to be trusted: lookup in the Broker's component registry. - Assuming that the NM's Subject refers to user information, the security information about the calling service (e.g. Subject) may be attached via NM's setProperty(...) method. - *Client side permission specification*: - Via group and user administration, or via a service engine replacing/complementing the AuthorizationMap (AuthorizationEntrys as SUs) Questions: 1. Are my assumptions about Security issues correct? (See page: "User's guide -> Security" in the confluence) 2. What do you think about this component? Is the outlined functionality already available in the current implementation? 3. Comments on/Ideas for implementation/realization? 4. My account in confluence seems to be disabled. When I log in, the system recognizes me but tells me: "You are not permitted to perform this operation." Any ideas? Thanks in advance, Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
