You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2012/07/31 22:37:48 UTC

[Bug 53633] New: Scope of Realm expanded when using SSO

https://issues.apache.org/bugzilla/show_bug.cgi?id=53633

          Priority: P2
            Bug ID: 53633
          Assignee: dev@tomcat.apache.org
           Summary: Scope of Realm expanded when using SSO
          Severity: normal
    Classification: Unclassified
                OS: Linux
          Reporter: dverbeek@hotmail.com
          Hardware: PC
            Status: NEW
           Version: 6.0.33
         Component: Catalina
           Product: Tomcat 6

A Realm defined within a Host should be shared with all webapps within that
Host when using SSO, EXCEPT for webapps that define their own Realm. This kinda
works, but the specific Realm defined within a nested Context seems to be
shared also. (No new challenge for authentication is presented.)

Example (server.xml):
<Host>
<Realm className="...JDBCRealm" />

<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

<Context path="/manager" privileged="true">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Context>

</Host>

In this scenario the webapps that use the shared JDBCRealm use
FormAuthentication.The manager webapp uses BasicAuthentication of course. Now
once a user has logged in with the manager webapp the user is also
authenticated for all other webapps. The reverse scenario does seem to work
somewhat better. Once a user has logged in with any other webapp than manager,
accessing the manager webapp yields a http 403 status. As if there was no user
database defined for the manager app. Are Principals cached in a central
location perhaps?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 53633] Scope of Realm expanded when using SSO

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53633

--- Comment #2 from Dennis Verbeek <dv...@hotmail.com> ---
(In reply to comment #1)
> As per the docs, if you use SSO all contexts must use the same Realm. The
> behaviour is undefined if you don't follow that requirement.

Looking back at it, I cannot believe I missed that.

So just to be clear, especially for everybody stumbling upon the same issue,
there are two options to make it work as expected:

1 - Include the proper role for the manager webapp in the SSO-Realm. This
integrates the manager webapp with your own webapps. Vulnerabilities included.
2 - Create a separate Service/Connector/Engine/Host/Realm for the manager
webapp.

<Service name="Catalina">
...
</Service>

<Service name="manager">
  <Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" />
   <Engine name="Manager" defaultHost="manager">
      <Host name="manager" appBase="webapps"
        unpackWARs="true" autoDeploy="true"
        xmlValidation="false" xmlNamespaceAware="false">

        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
          resourceName="UserDatabase"/>

    </Host>
  </Engine>
</Service>

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 53633] Scope of Realm expanded when using SSO

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53633

--- Comment #3 from Konstantin Kolinko <kn...@gmail.com> ---
(In reply to comment #2)
> 2 - Create a separate Service/Connector/Engine/Host/Realm for the manager
> webapp.
> 

2 is a limited workaround, because the Manager webapp manages only the Host to
which it belongs.

It seems that you are creating two hosts which share the appbase directory. 
It will work only if the main host is configured with autoDeploy=true.
Uploading a new war file will work. Undeploying is likely to work as well.
You will not be able to properly stop/start your applications (but only their
copies in this "manager" host).

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 53633] Scope of Realm expanded when using SSO

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53633

--- Comment #4 from Dennis Verbeek <dv...@hotmail.com> ---
(In reply to comment #3)
> 2 is a limited workaround, because the Manager webapp manages only the Host
> to which it belongs.

Conclusion: Formally using the manager webapp with the provided Realm is
mutually exclusive from using SSO with its own Realm. Maybe this is a good
thing to explicitly mention in the documentation at the SSO Valve.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 53633] Scope of Realm expanded when using SSO

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53633

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
As per the docs, if you use SSO all contexts must use the same Realm. The
behaviour is undefined if you don't follow that requirement.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org