You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm@geronimo.apache.org by Apache Wiki <wi...@apache.org> on 2005/10/26 10:33:30 UTC
[Geronimo Wiki] Update of "Security" by djencks
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