You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm@geronimo.apache.org by sc...@geronimo.apache.org on 2004/11/20 09:14:09 UTC

[Apache Geronimo Wiki] New: Security

   Date: 2004-11-20T00:14:09
   Editor: AaronMulder <am...@alumni.princeton.edu>
   Wiki: Apache Geronimo Wiki
   Page: Security
   URL: http://wiki.apache.org/geronimo/Security

   no comment

New Page:

This page discusses security configuration in Geronimo, present and future.

Note that "present" describes CVS (which is very different from Milestone 3).

= Security Concepts =

'''Security Realm:''' This is what most app servers would consider to be a security realm.  It has a name, and a set of back-end stuff that makes authentication work.  It can do auditing and lockout and so on.  As it happens, under the covers, it uses a series of Login Modules to make this work.

'''Login Module:''' A JAAS LoginModule, which is a portable API for security services.  In theory any login module should work with any product; however, some of the ones we ship with Geronimo take advantage of Geronimo-specific features and wouldn't really work elsewhere.  Still, any portable JAAS login module developed elsewhere will run fine in Geronimo.  A Login Module may represent a back-end Login Domain, or it might just enforce a policy (such as auditing every login attempt).  It's up to you to arrange the login modules (order and control flags) in the Security Realm to get the desired effect.

'''Login Domain:''' What your network administrator might consider to be a security realm -- Active Directory, LDAP, a SQL database with security information, a Netegrity or RSA product, etc.  A valid source of authentication information (typically, users and groups).  When you successfully log in to a login domain, you get a set of Principals that identify you (usually one of type user and several of type group, though any type of Principal is possible).  The way for a Geronimo application to interact with a Login Domain is to configure a Login Module for that Login Domain, and then stuff the Login Module into a Security Realm.

'''Principal:''' Something that a Login Domain (via a LoginModule) uses to identify you.  Implements {{{java.security.Principal}}}.  Every Login Domain may use different Principal types.  So when you go to map users to J2EE roles, you need to say which Principal class / Principal name combinations map to each role -- the equivalent of "user Bob" or "group Developers" should be in a role.  You should also say which Login Domain this applies to, so if there were 2 different LDAP servers, you could say "user Bob from the Finance LDAP server and group Developers from the Engineering LDAP server" should be in a role.  However, that's not presently implemented correctly.

'''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

= Security Realms & Login Modules =



= Future Changes =