Subject | Authentication and authorization in Java 2 Enterprise Edition |
---|---|
Author | Roman Rokytskyy |
Post date | 2004-09-25T09:03:40Z |
Hi,
Let me explain how the security works in Java 2 Enterprise Edition
compliant servers. This is a standard in Java, so maybe we will find
something usefull there. Each method of the Enterprise Java Bean (a
component doing something useful) has a security descriptor assigned
to it. This is something very similar to GRANT <permission> ON
<myBean> TO <roleName>, in other words, the permission whether method
can be called or not is assigned to role, not to the user. That's all
the application server checks. Nothing else.
Now, how and where the mapping between user and role happens? There is
a whole framework responsible for this - JAAS - Java Authorization and
Authentication Specification. This is Sun's translation of the PAM.
User is required somehow to authenticate there. This is done via
callback mechanism. Application that tries to authenticate itself is
passed a set of "callbacks", each callback represents an alternative
method of authentication (e.g. username/password, etc.). Application
fills the required information and this information is passed to each
of the authentication plugins configured in the system together with
something called "subject". Plugin checks the passed information and
stores the authorization information in the subject. There are three
types of authorization information: principal (in our terms "a role"),
public credentials (e.g. public key for PKI infrastructure) and
private credentials (e.g. key for the symmetric encryption). Public
credential can be obtained by any part of code, private credential
must have a permission to be accessed (that is pure Java code security
concept, probably not applicable for Firebird). This "authenticated"
subject is assigned to the context of the request and is used by the
application server to check the permissions.
How we can use this stuff?
Consider following infrastructure:
- we have JAAS with two plugins - LDAP authentication and database
encryption plugin.
- user authenticates with username/password in the LDAP and his
subject is assigned a role (e.g. POWER_USER);
- subject with POWER_USER role is passed to the database encryption
plugin that assignes a private credential with an encryption key to
decode database (database pages or only metadata);
The rest is trivial. Subject is associated with connection and is used
on each database access. When you copy the database to some other
location, it does not matter whether you have an LDAP server that can
authenticate you as long as a key for a second plugin is not copied.
Hope this makes sense for a Firebird.
Roman
Let me explain how the security works in Java 2 Enterprise Edition
compliant servers. This is a standard in Java, so maybe we will find
something usefull there. Each method of the Enterprise Java Bean (a
component doing something useful) has a security descriptor assigned
to it. This is something very similar to GRANT <permission> ON
<myBean> TO <roleName>, in other words, the permission whether method
can be called or not is assigned to role, not to the user. That's all
the application server checks. Nothing else.
Now, how and where the mapping between user and role happens? There is
a whole framework responsible for this - JAAS - Java Authorization and
Authentication Specification. This is Sun's translation of the PAM.
User is required somehow to authenticate there. This is done via
callback mechanism. Application that tries to authenticate itself is
passed a set of "callbacks", each callback represents an alternative
method of authentication (e.g. username/password, etc.). Application
fills the required information and this information is passed to each
of the authentication plugins configured in the system together with
something called "subject". Plugin checks the passed information and
stores the authorization information in the subject. There are three
types of authorization information: principal (in our terms "a role"),
public credentials (e.g. public key for PKI infrastructure) and
private credentials (e.g. key for the symmetric encryption). Public
credential can be obtained by any part of code, private credential
must have a permission to be accessed (that is pure Java code security
concept, probably not applicable for Firebird). This "authenticated"
subject is assigned to the context of the request and is used by the
application server to check the permissions.
How we can use this stuff?
Consider following infrastructure:
- we have JAAS with two plugins - LDAP authentication and database
encryption plugin.
- user authenticates with username/password in the LDAP and his
subject is assigned a role (e.g. POWER_USER);
- subject with POWER_USER role is passed to the database encryption
plugin that assignes a private credential with an encryption key to
decode database (database pages or only metadata);
The rest is trivial. Subject is associated with connection and is used
on each database access. When you copy the database to some other
location, it does not matter whether you have an LDAP server that can
authenticate you as long as a key for a second plugin is not copied.
Hope this makes sense for a Firebird.
Roman