Date: 2004-11-20T01:52:03
Editor: AaronMulder <[EMAIL PROTECTED]>
Wiki: Apache Geronimo Wiki
Page: Security
URL: http://wiki.apache.org/geronimo/Security
no comment
Change Log:
------------------------------------------------------------------------------
@@ -77,6 +77,20 @@
</gbean>
}}}
+Note that a the Subject returned from a successfuly login in this fashion will
be a limited client-side Subject (because you're acting as a client of the
{{{LoginService}}}). To turn that into a full server-side Subject, you can
call {{{ContextManager.getServerSideSubject(clientSideSubject)}}}.
+
+=== Where This is Used ===
+
+The JMX remoting implementation looks for a configuration entry called "JMX".
You can either create a security realm with that name, or (more likely) add a
{{{ServerRealmConfigurationEntry}}} mapping "JMX" to some security realm name.
+
+The Jetty web container should let you configure a security realm in
{{{geronimo-jetty.xml}}} and then pop in a {{{JAASJettyRealm}}} that logs in
using the automatic configuration entry named for that security realm. The
second half of that works, but there's no entry in {{{geronimo-jetty.xml}}}
yet. Anyway, after login, Jetty probably wants to look up the server-side
Subject and use that (rather than the more limited client-side Subject).
+
+Tomcat or any other web container would need to do something similar.
+
+EJB containers don't need to do this, because the client will always log in
before invoking the EJB container. A web client is authenticated by the web
container using the web container's configured security realm, and an
application client is authenticated by some security realm specified on the
client side before connecting to the EJB container. In other words, the EJB
container always receives a Subject/Principals previously prepared, it never
gets a username and password that it needs to validate itself.
+
+Connectors are similar to EJB in that the caller should have authenticated
already. However, the connector might need to map the previous principals into
something the conector can use (e.g. application user "ammulder" should log in
to Oracle or SAP as "muldera" with a different password, or whatever). This is
only relevant for container-managed authentication, but that is relatively
popular. Currently the strategy for this is to use a realm bridge, though that
might be adjusted in the future (to just add secondary login modules that
provide connector-specific Principals at the normal login time).
+
== Configuring Clients to Talk to Security Realms ==
This is pretty much the same, only you need to manually configure the client
to use a {{{JaasLoginCoordinator}}}, and give it the realm name and server
host/port as options. Typically, you'd use a JAAS configuration file to do
this, with an entry like this:
@@ -110,7 +124,10 @@
* Auto-mapping of principals to groups needs to be enhanced (better
configuration, etc.)
* The client-side Subject should be given all the Principals generated by
server-side login modules (but not {{{RealmPrincipal}}}s). There should be a
configuration option to disable this.
* The old functionality to get a list of all available users and groups from
a security realm has been broken. It needs to be brought back in the form of a
helper class that can be configured on the {{{GenericSecurityRealm}}}, but they
need to handle arbitrary principal classes (not just "users" and "groups").
- * Replace the static registration with {{{GeronimoLoginConfiguration}}} with
an IOC assignment of GLC to each security realm.
+ * Replace the static registration with {{{GeronimoLoginConfiguration}}} with
an IOC assignment of GLC to each security realm (or better yet, vice versa).
+ * Update {{{geronimo-jetty.xml}}} to have the name of the security realm that
Jetty should use to authenticate to. Currently that's in a separate GBean,
which is kind of icky and is subject to naming collisions across web apps
+ * Handle user-provided {{{CallbackHandler}}}s in J2EE client applications
+ * Maybe automatically return the server-side Subject for server-side usage of
{{{JaasLoginCoordinator}}}
* Add some kind of fancier validator object to a {{{SecurityRealm}}} that can
enforce rules like "user only valid between 9 and 5". It can't only reject new
logins; it must also terminate an existing valid login at the appropriate time.
It's not clear how to do this right. This would replace the previous ability
to set a realm-specific max login duration.
* Potentially replace realm bridges with connector-specific {{{LoginModule}}}
classes that just add additional Principals to the Subject at the initial
authentication time.
* We need more tests of all this functionality
