Mailing-List: contact scm-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: scm@geronimo.apache.org
To: scm@geronimo.apache.org
Subject: =?iso-8859-1?q?=5BApache_Geronimo_Wiki=5D_New=3A__Security?=
Date: Sat, 20 Nov 2004 08:14:09 -0000
Message-ID: <20041120081409.44042.84013@minotaur.apache.org>

   Date: 2004-11-20T00:14:09
   Editor: AaronMulder <ammulder@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=
).

=3D Security Concepts =3D

'''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 auth=
entication 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 securit=
y services.  In theory any login module should work with any product; howev=
er, some of the ones we ship with Geronimo take advantage of Geronimo-speci=
fic 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 info=
rmation, a Netegrity or RSA product, etc.  A valid source of authentication=
 information (typically, users and groups).  When you successfully log in t=
o a login domain, you get a set of Principals that identify you (usually on=
e of type user and several of type group, though any type of Principal is p=
ossible).  The way for a Geronimo application to interact with a Login Doma=
in 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 Domai=
n may use different Principal types.  So when you go to map users to J2EE r=
oles, you need to say which Principal class / Principal name combinations m=
ap to each role -- the equivalent of "user Bob" or "group Developers" shoul=
d 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 F=
inance LDAP server and group Developers from the Engineering LDAP server" s=
hould 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 part=
icular login module succeeds or fails.  For the specific options and what t=
hey mean, see http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/l=
ogin/Configuration.html

=3D Security Realms & Login Modules =3D


=3D Future Changes =3D