High This change http://svn.atlassian.com/fisheye/changelog/public?cs=39411 http://svn.atlassian.com/fisheye/cru/CR-517#c3145 has broken confluence's invite plugin.
The plugin used to rely on the fact that after calling getAuthenticator().login(ServletActionContext.getRequest(), ServletActionContext.getResponse(), username, password, true); the request.getRemoteUser will return the username of logged in user. After we changed the BaseLoginFilter to cache the principle it no longer does that.
I changed the plugin so it is no longer affected...
- causes
-
CONFSERVER-21201 Bug in seraph breaks custom authenticators
-
- Closed
-
-
-
- Closed
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[SER-154] request.getRemoteUser() does not return a logged in user
Upped the severity of the issue as it has happened to several customers already.
SSO generally get exteral website to authenticate the user (e.g. apache to authenticate the user). We can get this user from "HttpServletRequest.getRemoteUser". However, Seraph wraps the HttpServletRequest inside a SecurityHttpRequestWrapper and overwrites the getRemoteUser method to look in the places that Seraph gets the user from (e.g. the session, cookie, basic auth,...). By default, Seraph never calls getRemoteUser to find the user which means SSO wont work. This means that people will be forced to write their own Authenticator. Most of them overwrite the getUserMethod to return the user from the Request:
public class Example extends DefaultAuthenticator {
public Principal getUser(HttpServletRequest request, HttpServletResponse response) {
return request.getRemoteUser();
}
}
In Seraph this used to work in a round about way in 2.1.
SecurityFilter -> Example.getUser(SecurityHttpRequestWrapper) -> SecurityHttpRequestWrapper.getRemoveUser -> Example.getUser(HttpRequest) -> HttpRequest.getRemoveUser.
Note that Example.getUser is called twice: once with the SecurityHttpRequestWrapper and the next time with the raw HttpRequest. The net result of all these calls is that eventually Example.getUser is given the raw request which allows it to return the user set by the SSO.
However, since the 2.2 the SecurityHttpRequestWrapper no longer calls back onto Example with the raw request but rather only looks for the user in Seraph cache.
SecurityFilter -> Example.getUser(SecurityHttpRequestWrapper) -> SecurityHttpRequestWrapper.getRemoveUser -> authenticationContext.getUser()
Unfortunately, this user will never be set because its the SSO that did the authentication and not Seraph. The means that the Example.getUser(SecurityHttpRequestWrapper) will always return null.
This is also a problem for customers who have custom authenticators in Confluence if they rely on request.getRemoteUser() to return the logged in user, for example if the user has alrerdy been logged in using SSO.
You can get at the underlying request using the following code: