Introduction

Starting in Geronimo 2.0.1 we have adopted the basic principle that all security flows from Subjects that result from logging in to a security realm. In previous geronimo releases security information for run-as and default subjects was constructed entirely outside any security realm. As a result of following the new principle run-as and default identities can now participate fully in security using such features as named credentials to access such external systems as connectors and web services, and the JACC system is now more fully pluggable.

...

Each application can choose to use a default, global, credential store or specify a specific store, perhaps specific to that application.

Configuring a SimpleCredentialStoreImpl

For each Subject accessible through a credential store you need to specify an id, the realm to log in to, and credentials, which depend on the security realm requirements but are typically the name and password. The schema is as follows:

...

Again, note that the PasswordCallbackHandler value element contains a plaintext password for the user.

Configuring your application to use a particular CredentialStore

Note that this aspect of geronimo security is completely pluggable and only the default implementation is described here.

...

The credential store to use is specified in the credential-store-ref. Normally you only need only supply the name component of the credential store name: for most purposes you are likey likely to include an app specific credential store in the app plan, but otherwise you need to assure that the credential store gbean is in the ancestor configurations of the application.

A default subject or each run-as role specifies the information needed to get the subject using a subject-infoType element.To be continued...

      <security use-context-handler="false" xmlns="http://geronimo.apache.org/xml/ns/security-2.0">
        <default-subject>
          <realm>my-properties-realm</realm>
          <id>default</id>
        </default-subject>
        <role-mappings>
          <role role-name="Administrator">
            <principal class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal" name="system"/>
          </role>
          <role role-name="User">
            <run-as-subject>
                <realm>my-properties-realm</realm>
                <id>user-run-as</id>
            </run-as-subject>the loi
            <principal class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="user"/>
          </role>
        </role-mappings>
      </security>

The sample above shows the simplest principal-role mapping: you specify the principal class and name for each principal that maps to a certain role. Normally this will be entirely sufficient to distinguish principals. However, you might have several login modules or security realms that can produce the same principal but with different meanings. In this case you can include the login domain name or realm name to distinguish the principals.

<!-- normal, no domain or realm info -->
<principal class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="user"/>

<!-- login domain name specified -->
<login-domain-principal domain-name="mydomain" class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="user"/>

<~-- realm name and login domain name specified>
<realm-principal realm-name="my-properties-realm" domain-name="mydomain" class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="user"/>