RemoteSSO - web.xml issues

[Migrated From Jforum.net]

Hi
As per the documentation given in the Jforum website if I want to implement RemoteUserSSO, I have to keep the following in web.xml but this code is throwing 403.Its acting as a show stopper. If I remove this entry from web.xml it works fine without SSO stuff. But I need SSO and it should work. I changed only web.xml , SystemGlobals.properties and RemoteUserSSO. Please let me know whether i am doing properly or missing something. I am using Acegi security which holds all user info in session. I am fetching email,password from Acegi and setting it to Httpsession object in RemoteUserSSO.

web.xml

<security-role>

<role-name>user</role-name>

</security-role>

<security-constraint>

<web-resource-collection>

<web-resource-name>Restricted Area</web-resource-name>

<url-pattern>*.page</url-pattern>

</web-resource-collection>

<auth-constraint>

<role-name>user</role-name>

</auth-constraint>

</security-constraint>

<login-config>

<auth-method>BASIC</auth-method>

</login-config>


1) SystemGlobals.properties
# defines the authentication method to sso
authentication. Type = sso
# defines the default class RemoteUserSSO
sso.implementation = com.mob.forum.sso.RemoteUserSSO


RemoteUserSSO


public String authenticateUser(RequestContext request)
{
HttpSession session = (HttpSession) JForumExecutionContext.getRequest().getSessionContext();
User userObj = (User) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
String username = userObj.getEmail();
String password = userObj.getPassword();

System.out.println(":::::::userObj "+userObj );
System.out.println(":::::::session "+session );
System.out.println(":::::::UserId"+username) ;
System.out.println(":::::::password"+password);

session.setAttribute("sso.password.attribute", password);
session.setAttribute("sso.email.attribute", username) ;

//HttpSession session = request.getSessionContext();

return request.getRemoteUser();
}


[originally posted on jforum.net by gregjhonson]

[Migrated From Jforum.net]

I think you are mixing security models here. It looks like Acegi is probably an web app based model and not a web app container based model.

The security constraints entries in the web.xml are standard Java Servlet spec stuff. This is telling the web app to secure the jforum *.page URLs and request login information via a BASIC web browser dialog. According to the specs, it is then up to the application container (e.g. Tomcat) to supply the authentication and associated role info.

E.g, with Tomcat, there has to be a REALM config property defined. Like the default MemoryRealm (or some such) that gets user and role info from an XML file in the config directory.

So, the CONTAINER is trying to secure the webapp using it's rules.. which are probably not set up correctly at the container level... and the Acegi app is trying to secure this at a lower level.

Anyway, somewhere in this either the user can't be authenticated to the servlet container or the authenticated user is not being identified at the container level as a member of the user role. Probably the latter since you get a 403.. which generally means, I know you you are, but you're not authorized (e.g. a member of the user role).

I think you might want to just put a normal html or jsp file in the web app and then make sure that you can log in via Acegi and access that first. Then move on to securing/solving any SSO issues.
[originally posted on jforum.net by monroe]

[Migrated From Jforum.net]

Thanks a lot Manroe. You rock


[originally posted on jforum.net by gregjhonson]

[Migrated From Jforum.net]

My development environment is using Tomcat but Production will be Jboss. As per your answer RemoteSSO is tightly coupled with the container realm. So can i drop this RemoteSSO and instead go for Cookie implementation? I want a container independant solution.


Thanks
Greg
[originally posted on jforum.net by gregjhonson]

[Migrated From Jforum.net]

Well, I looked quickly at the Acegi docs.. It looks like this is configured as a filter in the web.xml. If that is the security level you want to use, you should be able to drop the security constraints. These should be handled by the Acegi filter configuration.

If you do this, I would think your modified code (which really isn't using the request.getRemoteUser() call anymore) should work with Acegi. Assuming you don't want anonymous access that is.

E.g., if Acegi secures the entire webapp, (some Acegi filter on /*), then if a user ties to access it, the Acegi filters should handle identifying the user (e.g. prompt for id/password or use the current info). Then the modified remoteSSO code can get the information from Acegi.

The web container security filters are not needed in this scenario.
[originally posted on jforum.net by monroe]