geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Apache Geronimo Wiki] Updated: Security
Date Sat, 20 Nov 2004 09:52:03 GMT
   Date: 2004-11-20T01:52:03
   Editor: AaronMulder <>
   Wiki: Apache Geronimo Wiki
   Page: Security

   no comment

Change Log:

@@ -77,6 +77,20 @@
+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
  * 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

View raw message