geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s..@geronimo.apache.org
Subject [Apache Geronimo Wiki] Updated: Security
Date Tue, 23 Nov 2004 02:49:11 GMT
   Date: 2004-11-22T18:49:11
   Editor: AaronMulder <ammulder@alumni.princeton.edu>
   Wiki: Apache Geronimo Wiki
   Page: Security
   URL: http://wiki.apache.org/geronimo/Security

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -16,6 +16,8 @@
 
 '''Subject:''' In JAAS, every user is represented by a Subject.  The Subject holds a collection
of all the Principals for the user.  It may also hold credentials such as the password or
certificate used to log in.  When a user logs in to Geronimo, the server gets a fully-populated
Subject for the user.  The client side of this transaction only gets a partially populated
Subject, but it's enough to identify the user to the server so the server can use it's fully-populated
Subject for anything it needs to do.
 
+'''!RealmPrincipal:''' For every principal generated by a login domain, Geronimo creates
a matching {{{RealmPrincipal}}} principal that identifies both the original principal and
the login domain.  When Geronimo does authorizations, it matches the current Subject's {{{RealmPrincipal}}}s
to the required {{{RealmPrincipal}}}s.  This allows role mapping to correctly process multiple
principals with the same name and/or Principal type (class), but from different login domains
(user "admin" from domain IT and group "admin" from domain "Finance", for example).
+
 = Current State =
 
 == Configuring LoginModules and Security Realms ==
@@ -33,6 +35,9 @@
         usersURI=var/security/users.properties
         groupsURI=var/security/groups.properties
     </attribute>
+    <attribute name="loginDomainName" type="java.lang.String">
+        geronimo-properties-realm
+    </attribute>
 </gbean>
 
 <gbean name="geronimo.security:type=LoginModule,name=credential-populator"
@@ -57,7 +62,13 @@
 </gbean>
 }}}
 
-In this example we configure a {{{PropertiesFileLoginModule}}} (which loads users and groups
from separate files), and a credential populator (which stores a user's credentials for use
by realm bridges).  The properties file module takes options indicating where to find the
properties files, while the credential populator has no relevent options.  The security realm
configuration declares the properties file module as REQUISITE (it's required, and the login
will immediately fail if it doesn't succeed) and the credential populator as OPTIONAL (it
will be used, but if it doesn't succeed for some reason, we don't stop the login).
+In this example we configure a {{{PropertiesFileLoginModule}}} (which loads users and groups
from separate files), and a credential populator (which stores a user's credentials for use
by realm bridges).  The properties file module takes options indicating where to find the
properties files, while the credential populator has no relevent options.  The properties
file module represents a login domain (with a loginDomainName), while the credential populator
doesn't (it doesn't generate any principals).  The security realm configuration declares the
properties file module as REQUISITE (it's required, and the login will immediately fail if
it doesn't succeed) and the credential populator as OPTIONAL (it will be used, but if it doesn't
succeed for some reason, we don't stop the login).
+
+'''Note 1:''' The first module must be REQUIRED or OPTIONAL if you always want the second
module to be executed (for example, for an auditing module that should audit login failures
too).
+
+'''Note 2:''' If a login module will add Principals to the Subject, then it should have a
loginDomainName.  Otherwise, it should not (unless it will be registered as a standalone login
module instead of included as part of a realm).  Generally, login modules with a loginDomainName
may (but need not) implement {{{DeploymentSupport}}}.  A module without a loginDomainName
should not implement {{{DeploymentSupport}}}.
+
+'''Note 3:''' In today's implementation, the loginDomainName must match the realm name for
role mapping to work.  This means there can only be one login module representing a login
domain per realm.  This restriction will be removed in the future (once role mapping accounts
for login domain names).
 
 == Configuring Server Components to Talk to Security Realms ==
 
@@ -77,17 +88,17 @@
 </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)}}}.
+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}}}).  This gets
all the principals generated by the server-side login modules, but not any of the {{{RealmPrincipal}}}s
generated by Geronimo itself and used for role mapping / authorization by Geronimo.  To turn
the limited client-side Subject 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).
+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, since Jetty would need the {{{RealmPrincipal}}}s).
 
 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.
+EJB containers don't need to invoke the {{{JaasLoginCoordinator}}}, 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.  It still
needs to handle role mapping, and authorization against the current Subject, however.
 
 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).
 
@@ -112,20 +123,17 @@
 There are a number of to-dos in the security area:
 
  * We need to provide more login modules, including:
-   * One that audits every login attempt to a file in {{{var/}}} somewhere
    * One that rejects logins for a user after X unsuccessful attempts (in a row or in Y minutes)
    * One that validates against an LDAP login domain
    * One that validates client certificates against a particular certificate authority
  * The {{{SQLLoginModule}}} needs to be updated to execute user-specific queries instead
of loading the entire list of users and groups every time
- * The current {{{RealmPrincipal}}} gets the security realm name, whereas it really should
get the login domain name
- * Therefore, we need to be able to specify a login domain name for every login module
  * Role mapping needs to change to support login domain names
    * The mapping should go by login domain name, principal class, and principal name
    * You should be able to specify more than one default principal; for example, you might
want the default (unauthenticated) subject to get one user principal and two group principals
- * 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.
+ * Perhaps enforce rules about when loginDomainName should be set in the {{{LoginModuleGBean}}}
doStart method, or something like that.
+ * Auto-mapping of principals to groups needs to be enhanced (configured per login domain,
etc.)
  * Maybe automatically return the server-side Subject for server-side usage of {{{JaasLoginCoordinator}}}
- * 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").
+ * Fix the assignment of a {{{DeploymentSupport}}} class to the {{{GenericSecurityRealm}}}
-- as is, there's no way to configure the {{{DeploymentSupport}}} to point to a specific login
realm instance (LDAP server, DB, etc.)
  * 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

Mime
View raw message