[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Authenticatio/Authorization on "pull" message over a MPF.
The problem as I understand it is that we want to make
certain at the “server” side that a request for a message on a MPF
is only honored if the requesting agent is authorized to access that particular
MPF. That is, having the request be authenticated as from some party (data origin
authentication) is insufficient. An authorization “rule” needs be
be consulted to check whether a request from that authenticated identity is
authorized to pull a message on the MPF. That said, an additional constraint on solutions to the
problem is that the requesting party is possibly “PKI-challenged”
so that strong authentication approaches (involving signing of something)
cannot be required. Another constraint is that the desired solution must be
implemented across all (!) conformance profiles. An additional desired feature
is that the solution be independent of transfer protocol. Final design features
want the solution to be cleanly deployable across architectures involving many
SOAP intermediaries in the path. My proposal is that both HTTP basic authentication and WSS
Username token profile authentication be mandated. HTTP basic auth because it
is pervasive (though transfer protocol dependent) and WSS Username because it
is transfer protocol. Both authentication approaches may have some risk when
used without TLS. What we say about MPF processing is, however, that it must
check that the identity available through some supported means of
authentication be eligible to pull messages from the MPF. Other mechanisms of
authentication can be agreed upon (via a PMode? or via a CPA) but in any case,
the MPF supporting service must do the check that identity is authorized to use
resource MPF. We should also run this proposal (or its refinement reached
by this group) by the end user audiences we have already consulted, and verify with
them that the approach meets their requirements. Dale Moberg As to the deployability across any arbitrary SOAP path, with
any arbitrary targeting of headers, and with unknown header augmentations and
removals, I suspect something can be kludged up to work. (Check the HTTP basic
auth, add an ad hoc authentication header, email it to the next hop, etc, etc,
until something that needs to check the MPF and identity map pulls off the
identity header, and does its check). However, I am not interested in trying to
spec out all the possible permutations personally. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]