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 Sat, 20 Nov 2004 09:30:14 GMT
   Date: 2004-11-20T01:30:14
   Editor: AaronMulder <ammulder@alumni.princeton.edu>
   Wiki: Apache Geronimo Wiki
   Page: Security
   URL: http://wiki.apache.org/geronimo/Security

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -14,6 +14,8 @@
 
 '''Control Flag:''' There are 4 possible control flags for a login module, and they indicate
what should happen in the overall login process if a particular login module succeeds or fails.
 For the specific options and what they mean, see http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/login/Configuration.html
 
+'''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.
+
 = Current State =
 
 == Configuring LoginModules and Security Realms ==
@@ -99,13 +101,16 @@
    * 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 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 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}}}.
+ * 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.
  * 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

Mime
View raw message