Security and authorization requirements on RequestBroker

["Rossmanith, Philipp" <ph...@t-systems.es>]

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.