Simon -- see my comments below.
From the WikiContext constructor:
// Log in the user if new session or the container status
changed
boolean doLogin = (request != null) && m_session.isNew();
if( doLogin || m_session.isContainerStatusChanged( request ) )
{
try
{
engine.getAuthenticationManager().login( request );
}
catch ( WikiSecurityException e )
{
// Login failed because config was screwy
log.error( "Could not log in user: " +
e.getMessage() );
}
}
So here there is no attempt from jspwiki code to see whether there
is a
UserPrincipal in the current request; it just calls the login method
on
the AuthenticationManager whenever WikiSession.isNew returns true, ie
the first time a particular user accesses the wiki.
Not quite right. It will also invoke the JAAS login process if
isContainerStatusChanged() returns true, which it will if the remote
user, user princpal, or "assertion cookie" changes to some non-null
value. That will happen if and when ACEGI populates these values. So
I'd say the basic problem is that JSPWiki can't locate its JAAS config.
The AuthenticationManager.login call eventually ends up at
WikiSession.getLoginContext
which does:
return new LoginContext( application, m_subject, handler );
where LoginContext is a javax.security class. And that eventually
fails
to "initialise" the jaas system - which of course it will, because we
are not using the build-in jaas, but ACEGI instead.
Well, in this case what JSPWiki depends on is being able to find its
JAAS login configuration, called "JSPWiki-container". This stack
executes so that JSPWiki can pick up the container principal/remote
user. That's going to be true REGARDLESS of whether or not you use
ACEGI. So, put simply, JSPWiki must be able to find this
configuration. It's clearly not finding it in your case.
If ACEGI configures its own JAAS stack, then what you should do is
append the contents of jspwiki.jaas to it. That way, JSPWiki will be
able to find the correct login configuration. Then the login stack
will execute as we expect, and JSPWiki will be able to detect the
credentials ACEGI is passing.
I don't know where the "bug" might be here; whether it is my ACEGI
config or the way jspwiki uses javax.security or anything else. It's
well beyond my knowledge at this point :-(.
If anyone has a suggestion I'd be glad to try it (and report back),
but
otherwise I'll keep on with a custom AuthenticationManager...
You are welcome to do whatever you like, but at this point I'd say
this falls squarely into the realm of configuration, not programming.
Cheers,
Simon
