Anchor | ||||
---|---|---|---|---|
|
This article is an attempt to cover as many administrative tasks as possible, common and not so common tasks. This article is grouped in four main sections having a similar flow to what you would find while using the Geronimo Administration Console, this way should be easier for you to familiarize on both tasks and console.
...
If the server is already running you have the option of using the Geronimo Administration Console to shutdown the server remotely. With the server up and running open a Web browser and point to the following URL to access the console:
Log in to the Geronimo Administration Console and click on
Shutdown on the Console Navigation menul on the left....
- Request:
Lets you specify the Request Method from and the Requested URI. You can select the Requested Method from a drop-down menu, the possible values are ANY, POST and GET. To filter by Requested URI just enter a URI, for example http://localhost:8080/console/login.jsp.
...
You should now see the database pool you just imported listed in the database pool portlet.
Removing database pools
...
If you want to run any SQL command on this database make sure you select test from the Use DB: pull-down menu, enter the SQL command and then click on the Run SQL button. The results of the command will be displayed near the bottom of the protlet.
Configuring JMS
Connection factories, queues, topics and destinations.
To configure JMS, the JMS Connection Factories and JMS Destination Manager portlets are avaiable by selecting JMS on the Console Navigation menu on the left hand side. The JMS Connection Factories portlet illustrated in the following figure displays all the JMS connectors that are configured in the Geronimo server and allows you to add a new JMS Connection Factory.
The JMS Destination Manager portlet lists all the queues and topics that are configured in the Geronimo server.
In Apache Geronimo v1.0 these portlet are not totally implemented and you will need to create deployment plans and command line tools to deploy these configurations. Additional details for configuring JMS and Further details on JMS integration are covered in the Integrating A Third Party JMS Provider section.
...
Our taget now is "+ HelloWorld @ http://hcunico:8080/hello " , this module's status is started since there is a + on the left. Alternatively, you can run the following command to list just the started modules:
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
<configuration configId="SecurityRealm-derby_security_realm" xmlns="http://geronimo.apache.org/xml/ns/deployment-1.0"> <import> <uri>user/database-pool-SecurityDatabase/1/car</uri> </import> <gbean name="derby_security_realm" class="org.apache.geronimo.security.realm.GenericSecurityRealm"> <attribute name="realmName">derby_security_realm</attribute> <reference name="ServerInfo"> <gbean-name>geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo, j2eeType=GBean,name=ServerInfo</gbean-name> </reference> <reference name="LoginService"> <gbean-name>geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo, j2eeType=JaasLoginService,name=JaasLoginService</gbean-name> </reference> <xml-reference name="LoginModuleConfiguration"> <log:login-config xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-1.0"> <log:login-module control-flag="REQUIRED" server-side="true" wrap-principals="false"> <log:login-domain-name>derby_security_realm</log:login-domain-name> <log:login-module-class>org.apache.geronimo.security.realm.providers.SQLLoginModule</log:login-module-class> <log:option name="userSelect">select username, password from APP.users where username=?</log:option> <log:option name="dataSourceApplication">null</log:option> <log:option name="groupSelect">select username, groupname from APP.groups where username=?</log:option> <log:option name="dataSourceName">SecurityDatabase</log:option> </log:login-module> <log:login-module control-flag="OPTIONAL" server-side="true" wrap-principals="false"> <log:login-domain-name>derby_security_realm-Audit</log:login-domain-name> <log:login-module-class>org.apache.geronimo.security.realm.providers.FileAuditLoginModule</log:login-module-class> <log:option name="file">var/log/derby_security_realm.log</log:option> </log:login-module> <log:login-module control-flag="REQUISITE" server-side="true" wrap-principals="false"> <log:login-domain-name>derby_security_realm-Lockout</log:login-domain-name> <log:login-module-class>org.apache.geronimo.security.realm.providers.RepeatedFailureLockoutLoginModule</log:login-module-class> <log:option name="lockoutDurationSecs">60</log:option> <log:option name="failurePeriodSecs">10</log:option> <log:option name="failureCount">3</log:option> </log:login-module> </log:login-config> </xml-reference> </gbean> </configuration> |
...
Testing the security realm
If you want to quickly test this realm you can use the LDAP sample application covered in the Configuring LDAP section. You will just need to change the deployment descriptor geronimo-web.xml to the one shown in the following example, repackage the application and deploy it.
Note that we only changed from the original plan the realm name from ldap-realm to derby_security_realm.
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/web"
xmlns:sec="http://geronimo.apache.org/xml/ns/security"
configId="org/apache/geronimo/ldap-secure-demo">
<context-root>/ldap-demo</context-root>
<context-priority-classloader>false</context-priority-classloader>
<!-- <security-realm-name>ldap-realm</security-realm-name> -->
<security-realm-name>derby_security_realm</security-realm-name>
<security>
<default-principal realm-name="derby_security_realm">
<principal class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal" name="system"/>
</default-principal>
<role-mappings>
<role role-name="content-administrator">
<realm realm-name="derby_security_realm">
<principal class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="admin" designated-run-as="true"/>
<principal class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal" name="system"/>
</realm>
</role>
<role role-name="guest">
<realm realm-name="derby_security_realm">
<principal class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal" name="guest" designated-run-as="true"/>
<principal class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal" name="user1"/>
<principal class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal" name="user2"/>
</realm>
</role>
</role-mappings>
</security>
</web-app> |
Follow the instructions in the Configuring LDAP section to repackage and deploy the application. When you test it, this time you will using the database SQL realm. Give it a try a few times, you should see the successful login attempts recorded in the log file you specified when created this security realm (in this example var\log\derby_security_realm.log)
No Format | ||||
---|---|---|---|---|
| ||||
03/01/2006 15:56:33 - Authentication attempt - userone
03/01/2006 15:56:33 - Authentication succeeded - userone
03/01/2006 16:10:05 - Authentication attempt - usertwo
03/01/2006 16:10:05 - Authentication succeeded - usertwo |
Administering certificates
To administer SSL certificates the Keystore Configuration portlet in available by selecting Keystore on the Console Navigation menu on the left hand side. From this portlet you can either import an existing certificate or create a new certificate request.
The certificates in Geronimo are stored in a keystore located in <geronimo_home>\var\security\ssl-keystore-1. This ssl keystore file does not exist until you create the first private key.
If you already have a certificate you can click on import trusted certificate.
Specify the location of the certificate file and click View Certificate. The certificate information will be displayed, you may add an alias to identify this certificate, when done click on Import to add that certificate to the keystore. You should now see that the keystore size has increased.
To generate a key click on generate key pair. In the following screen enter the relevant information and click on Submit. For this example we entered the following values:
Alias: | Geronimo Server |
Key Algorithm: | RSA |
Key Size: | 1024 |
Signature Algorithm: | MD5withRSA |
Validity: | 2000 |
Common Name (CN): | 127.0.0.1 |
Organizational Unit (OU): | Geronimo |
Organizational Name (O): | Apache |
Locality (L): | Locality |
State (ST): | State |
Country (C): | Country |
You should now see that the keystore size has increased and the private key you just created is listed near the bottom of the Keystore Configuration portlet. Click on view next to the private key you created, you should see the details of this key pair and the options to generate a certificate request and to import a certificate reply from a certification authority (CA).
To generate a certificate request to send to a CA click on generate CSR, copy the content generated and send it to the CA (you would normally receive the instructions from the CA on how to send this CSR).
Once you receive the reply from the CA you will likely receive a certificate file, to add this certificate to the keystore follow the steps to import trusted certificate.
Using the certificates
Warning |
---|
There is currently a known issue using the certificates to secure new HTTPS listeners, there is a patch alredady available and it should be applied to the next release of Apache Geronimo, see JIRA GERONIMO-1503 for details. |
To use your own certificates instead of the one provided by default with the installation you need to create a new HTTPS listener. Use the Network Listener portlet available by selecting Web Server in the Console Navigation menu on the left hand side. The steps for adding a new HTTPS listener were covered earlier in the #Add new HTTPS listener section.