Hi,
On Fri, Feb 1, 2013 at 10:34 PM, Ron Monzillo <ron.monzillo_at_oracle.com>wrote:
>
> glassfish bundles the jaas authconfig provider (and factory) in a
> (maven) security module called
> JSR-196 Provider Framework Reference Implementation with artifact id
> jaspic.provider.framework
> This provider will also be made available from the Nobis project (we are
> working to ensure it is portable)
>
Okay, I'll try if I can experiment somewhat with that one.
> - Clarify that HttpServletRequest#login is not supported by JASPIC for the
> moment. An exception should be thrown instead of an invocation of some
> default unrelated login module. If it would be possible to specify how
> JASPIC can really handle HttpServletRequest#login then this would be even
> better.
>
> I think the exception approach sounds like a good one
>
I did find 1 vendor who implemented request#login for JASPIC, albeit in a
vendor specific way: IBM in WebSphere 8.5.
Because of a lot of issues I couldn't fully get my JASPIC example code to
work on WebSphere 8.5, but I could test that the JASPIC module is indeed
being called following request#login. In that case, the Map in the
MessageInfo parameter contains 3 entries; 1 indicating there's a login (or
authenticate) being called, and the other two contain the username and
password in case of a login call:
com.ibm.websphere.jaspi.request = "login" / "authenticate"
com.ibm.websphere.jaspi.user = [username provided in request#login call]
com.ibm.websphere.jaspi.password = [password provided in request#login call]
IBM documents those 3 parameters via an example in the last part of step 4
here:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Fae%2Ftsec_jaspi_create.html
>
> I won't be able to do the following at this time, but would be happy to
> work with you to see how they might be done.
>
Sounds great, looking forward to that.
Grtz,
Arjan Tijms