geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Geronimo Wiki] Update of "Security" by djencks
Date Wed, 26 Oct 2005 08:33:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by djencks:
http://wiki.apache.org/geronimo/Security

The comment on the change is:
An attempt to remove some of the more egregious misinformation from this page

------------------------------------------------------------------------------
- This page discusses security configuration in Geronimo, present and future.
+ This page is an extremely incomplete discussion of security configuration in Geronimo, present
and future.
  
- Note that "present" describes CVS (which is very different from Milestone 3).
+ Note that "present" is as of late October 2005, post M5.
  
  ''(see also JettyHttpsConfiguration for info on configuring Jetty to support ssl/https)''
  
@@ -20, +20 @@

  
  '''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).
+ '''!DomainPrincipal:''' For every principal generated by a login domain, Geronimo may create
a matching {{{DomainPrincipal}}} principal that includes both the original principal and the
login domain name.  
  
+ '''!RealmPrincipal:''' For every principal generated by a login domain within a realm, Geronimo
may create a matching {{{RealmPrincipal}}} principal that includes the DomainPrincipal and
the realm name.
+ 
+ 
+ = Authorization =
+ 
+ The j2ee declarative security model is based on roles, whereas the JAAS login model is based
on principals. We need to map the principals to roles to determine if a particular user has
a particular permission.  This principal-role mapping is described in a security element in
a geronimo j2ee plan.  For each role, the principals that map to it are specified.  These
can be plain unwrapped principals direct from a login module, or domain or realm principals
that include the login domain name and the realm name respectively. Most simple geronimo deployments
can use the plain unwrapped principals.  You should consider using the wrapped domain principals
if you have 2 or more login domains that return the same principal class and name but the
origin of the principal is needed to determine permissions.  For instance, you might have
2 LDAP systems with the same group names, but with different meanings.  Labeling the principals
with the login domain will enable geronimo to distingui
 sh which LDAP system was used to authenticate the user.  A further level of control is supplied
by using the RealmPrincipal, which also includes the realm name. This enables geronimo to
distinguish between uses of the same login module in two realms.  One possible use of this
might be if one realm contains additional or different login modules.  
+   
  = Current State =
  
  == Configuring LoginModules and Security Realms ==
  
- To configure a security realm, you must first declare login modules (one GBean each) and
then declare a security realm that uses those login modules.  Here's an example:
+ Here's an example of a security realm with 2 login modules, that produces only plain unwrapped
principals:
  
  {{{
- <gbean name="geronimo.security:type=LoginModule,name=properties-login"
-     class="org.apache.geronimo.security.jaas.LoginModuleGBean">
-     <attribute name="loginModuleClass" type="java.lang.String">
-         org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
-     </attribute>
-     <attribute name="serverSide" type="boolean">true</attribute>
-     <attribute name="options" type="java.util.Properties">
-         usersURI=var/security/users.properties
-         groupsURI=var/security/groups.properties
-     </attribute>
-     <attribute name="loginDomainName" type="java.lang.String">
-         geronimo-properties-realm
-     </attribute>
+     <gbean name="client-properties-realm"
+         class="org.apache.geronimo.security.realm.GenericSecurityRealm">
+         <attribute name="realmName">client-properties-realm</attribute>
+         <xml-reference name="LoginModuleConfiguration">
+             <lc:login-config xmlns:lc="http://geronimo.apache.org/xml/ns/loginconfig">
+                 <lc:login-module control-flag="REQUIRED" server-side="true">
+                     <lc:login-domain-name>client-properties-realm</lc:login-domain-name>
+                     <lc:login-module-class>org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule</lc:login-module-class>
+                     <lc:option name="usersURI">var/security/users.properties</lc:option>
+                     <lc:option name="groupsURI">var/security/groups.properties</lc:option>
+                 </lc:login-module>
+                 <lc:login-module control-flag="REQUIRED" server-side="true">
+                     <lc:login-domain-name>default</lc:login-domain-name>
+                     <lc:login-module-class>org.apache.geronimo.security.jaas.NamedUPCredentialLoginModule</lc:login-module-class>
+                     <lc:option name="org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name">default</lc:option>
+                 </lc:login-module>
+             </lc:login-config>
+         </xml-reference>
+         <reference name="ServerInfo">
+             <module>org/apache/geronimo/System</module>
+             <name>ServerInfo</name>
+         </reference>
+         <reference name="LoginService">
+             <name>JaasLoginService</name>
+         </reference>
- </gbean>
+     </gbean>
  
- <gbean name="geronimo.security:type=LoginModule,name=credential-populator"
-     class="org.apache.geronimo.security.jaas.LoginModuleGBean">
-     <attribute name="loginModuleClass" type="java.lang.String">
-         org.apache.geronimo.security.realm.providers.GeronimoPasswordCredentialLoginModule
-     </attribute>
-     <attribute name="serverSide" type="boolean">true</attribute>
- </gbean>
- 
- <gbean name="geronimo.security:type=SecurityRealm,realm=geronimo-properties-realm"
-        class="org.apache.geronimo.security.realm.GenericSecurityRealm">
-     <attribute name="realmName" type="java.lang.String">geronimo-properties-realm</attribute>
-     <attribute name="loginModuleConfiguration" type="java.util.Properties">
-         LoginModule.1.REQUISITE=geronimo.security:type=LoginModule,name=properties-login
-         LoginModule.2.OPTIONAL=geronimo.security:type=LoginModule,name=credential-populator
-     </attribute>
-     <reference name="ServerInfo">geronimo.system:role=ServerInfo</reference>
-     <attribute name="autoMapPrincipalClasses" type="java.lang.String">
-         org.apache.geronimo.security.realm.providers.PropertiesFileGroupPrincipal
-     </attribute>
- </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 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).
+ 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 in the
Subject).  The properties file module takes options indicating where to find the properties
files, while the credential populator includes the domain name of the credential to be created.
 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 both login modules as REQUIRED.
  
  '''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 you need to use DomainPrincipals or RealmPrincipals to distinguish principals
of the same class and name, you should supply a domain name for your login module.
- '''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 ==
  
@@ -97, +94 @@

  === 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-web.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-web.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 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.
  
@@ -137, +130 @@

   * 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}}}
-  * 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-web.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
   * 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