Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4963CC97.2020503@fortybeans.com>
Date: Tue, 06 Jan 2009 21:26:47 +0000
From: Darren Hague <dhague@fortybeans.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: esme-dev@incubator.apache.org
Subject: Re: Scrum call summary (authentication section)
References: <28282009.1254601231267897228.JavaMail.servlet@kundenserver>
	 <cdbebedf0901061145pabddaey21efd222e1fd3cd4@mail.gmail.com>
	 <2bca8c350901061205k7271f87y52918cd1967255c0@mail.gmail.com>
	 <cdbebedf0901061255w7b77cc6ft26be983ac02dca18@mail.gmail.com>
 <2bca8c350901061313u4f58777g5622ebfbb163a12e@mail.gmail.com>
In-Reply-To: <2bca8c350901061313u4f58777g5622ebfbb163a12e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
> <feeder.of.the.bears@gmail.com>wrote:
>
>   
>> On Tue, Jan 6, 2009 at 12:05 PM, Daniel Koller <dakoller@googlemail.com
>>     
>>> 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
>
>