So long as it's pluggable (i.e. the built-in OpenID support can be
disabled or simply not used), then we should be fine.
The problem with implementing an OpenID JAAS module is that it requires
access to the HTTP Response object in the login module to achieve the
OpenID redirect. As far as I know, that is only possible using SAP's
J2EE engine at this stage (JAAS is not restricted to web applications
and only SAP have added a pair of callbacks to give access to the HTTP
request/response).
I have implemented such a login module already, but because of this
restriction, it only works with SAP NetWeaver at this point.
- Darren
Daniel Koller wrote:
On Tue, Jan 6, 2009 at 9:55 PM, David Pollak
<[email protected]>wrote:
On Tue, Jan 6, 2009 at 12:05 PM, Daniel Koller <[email protected]
wrote:
Hi,
is it possible to standardize the interface from ESME to the servlet
container:
I'd strongly prefer not to do that. It's fine for the auth plugin to do
that, but this would mean that the container needs to support OpenID if an
ESME instance is to support OpenID.
...the reason for my statement was, that the set of needed auth schemes is
up to infrastructure setup, where ESME is used.
So an OpenID JAAS Provider can be used and this does not limit our options
in the ESME code. Using this way we could also decouple ESME roadmap from
any upcoming acitivities/issues in the OpenID space.
And on the other hand, the primary support for openid in the ESME code could
reduce the resources available for supporting other auth schemes in the ESME
code: a primary OpenID requirement (with a difficult setup to circumvent
OpenID) would not help.
Daniel
