|
|
| Home > Documentation > Apache Geronimo v1.0 - User's Guide > Security > Security concepts |
This article explains some basic the rational and working of the Apache Geronimo security system. JAAC implementation will not be addressed in this article. The basic concepts on which Geronimo security architecture is build are: Login Domain and Security Realm. These concepts are integrated into the JAAS architecture for use by the container.
A lot of the security terms are overloaded, and you may find many definitions of principals, roles, etc. This article tries to stay with the established frameworks where possible such as OASIS SAML reference model.
According to the SAML specification a principal is a system entity whose identity can be authenticated. An Identity Provider is a service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers.
A principal can have any number of attributes, identity is just one of them, Other attributes are groups or locations for example. Logically these values are asserted by the Attribute Authority based on the identity. In practice, the Identity Provider and the Attribute Authority are usually collocated - although in complex SOA models providers can form a federation for identities and attributes.
Note that the reliance on Identity Provider and Attribute Provider implies certain level of trust between the Geronimo server and service providers. How trust is established is out of scope here, but it could be implicit, by agreement, by assertion, etc.
What is described here as the Identity Provider and Attribute Authority together with the established trust relationship Geronimo calls Login Domain. JAAS login modules (that abstract login domains) query for the identity and group attributes of a principal and believe that they are authentic.
One example of Login Domain is LDAP directory server, it combines maintenance of identity information and other attributes (such as groups). Relational databases with tables for users and groups is another.
Security realm configures and enforces application-specific authentication policy and is the entry point into login domains. Security realm implements pluggable authentication framework allowing for a combination of authentication protocols with different properties and different trust relationships that match application requirements.
Authentication policy for the security realm is expressed as a statement over authentication outcome of configured login domains.
For example, you can configure security realm with two login domains, for example kerberos and active directory, and require that both of them succeed for the authentication to succeed. Or you can configure a security realm with the LDAP directory login domain without any regard for the authentication outcome from it (maybe because you do not trust it). The point here is that you express an authentication policy and you have a security realm enforce it.
Of course, security realm authentication policy emulates JAAS login module combination semantics. In fact, security realm implementation is wired with the JAAS login modules that are configured with the familiar attributes such as control flag and options. The authentication procedure is driven by the Login Module JAAS API and the authentication result is computed over control flag values and authentication outcomes of individual login modules.
As authentication proceeds each login domain (implemented by the login module), it creates it's own principals that implement java.security.Principal interface. There are several implementations of the java.security.Principal interface in Geronimoas illustrated in the following table:
Principals are created by the login domains, so ideally a principal must be associated with the login domain. To that end, org.apache.geronimo.security.DomainPrincipal will wrap every principal created by the login module (login domain) and in turn it will be wrapped by the org.apache.geronimo.security.RealmPrincipal if security realm is configured to wrap login modules.
Despite it's name, the org.apache.geronimo.security.realm.providers.GeronimoCallerPrincipal interface is just a marker and is implemented by the org.apache.geronimo.security.providers.GeronimoUserPrincipal. This type of principal is added to the set of principals of the Subject within login modules distributed with Geronimo. There is no interface that would assure GeronimoUserPrincipal is indeed included, so do not forget about it if you write your own login module. In fact, some of the Geronimo login modules do not include this type of principal (for example FileAuditLoginModule).
There are some special types of Principal's that are created after authentication procedure succeeds and used by Geronimo to track authenticated subject through it's lifetime in the container.
Bookmark this on Delicious
Digg this
|
Privacy Policy - Copyright © 2003-2009, The Apache Software Foundation, Licensed under ASL 2.0. |
