Re: question about appropriate behavior when no web services are installed
I am thinking (1). Some apps would require the web services to be functional from an end user point of view, but other apps may have multiple methods of access, web services being one of them and may be able to operate with partial functionality, but even in this case, it would most likely be impacting some end users and we should probably refuse to deploy the app. This sounds related to http://issues.apache.org/jira/browse/GERONIMO-556 John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. David Jencks <[EMAIL PROTECTED]> 19-Apr-2005 05:17 AM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject question about appropriate behavior when no web services are installed Due to our modular architecture, we should be able to set up geronimo so that it will deploy web apps or ejb modules but not web services. Assuming we have such a geronimo configuration, what should happen when someone tries to deploy a module that does include web services, as indicated by a webservices.xml deployment descriptor? (1) refuse to deploy the app (2) deploy the non-webservice parts of the app What should happen when such a module tries to use web services via a service-ref? (1) refuse to deploy the app (2) deploy the app, but not bind anything for the service ref into jndi. thanks david jencks
Re: Should J2EE apps be using the SystemDatasource ?
Bruce Snyder wrote: On 4/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Is the SystemDatasource only intended for the internal use of Geronimo and associated components (e.g. Geronimo's "timertasks" table, ActiveMQ's tables ) and not intended for direct use by J2EE applications? I am guessing some reasons for this could be: * safety - we don't want J2EE apps playing with our internal tables or have any table name conflicts with J2EE apps * performance? There is another possible safety issue. From my understanding of the specs, JSR 151 J2EE.2.5 requires a JDBC database to be accessible from a client container. To me, that requires or implies a client application running on a remote machine must be able to access Derby. That means Derby must be configured to listen on an external network interface, or Geronimo needs to provide a JDBC listener to delegate to Derby. Here are some thoughts. If I'm I'm off base or if these issues already have been addressed, please let me know. o The SystemDatabase configuration sets up Derby to listen only on localhost. That means external client containers won't be able to access the JDBC database by connecting directly to Derby. Will this setup pass certification tests, or is another mechanism provided for remote J2EE clients to access the database? o If Derby is set up to listen on 0.0.0.0 or the server's external interface, Derby should be set up to require authentication to close the security hole of any client being able to modify any Derby database. o The Geronimo J2EE client container could be set up to provide a DataSource through JNDI that prohibits access to the SystemDatabase. That would provide some level of protection. But if Derby is listening on a public interface, requiring client authentication would still be a good idea. Does anyone know of any other tables that will be placed in the SystemDatasource? some notes for future reference... Geronimo's "timertasks" table creation statements are in geronimo\modules\timer\src\java\org\apache\geronimo\timer\jdbc\JDBCWorkerPersistence.java ActiveMQ's table creation statements are in the getCreateSchemaStatments (..) method in activemq\modules\core\src\java\org\activemq\store\jdbc\adapter\DefaultStatementProvider.java I agree that we don't want J2EE apps messing with system related resources like the SystemDatasource, but I don't know that there is any manner in which to scope such resources only for use by the kernel or GBean-wrapped components. Is there any such feature? Bruce Derby provides three modes of user authentication: using an LDAP server, the "BUILTIN" user repository that uses system properties for usernames and passwords, or providing a custom "UserAuthenticator" class. Once authentication is enabled, you can restrict access to Derby's SystemDatabase by setting the "defaultConnectionMode" property to "noAccess" or "readOnlyAccess" to limit what outsiders can do to the database. That would mean Geronimo needs to login to Derby as an authorized user, or (continue to use?) the embedded JDBC driver, which I think bypasses security. One shortcoming with authorization: the current version of Derby allows all authenticated users to shutdown Derby if they connect from localhost. You don't need a special authorization level to shutdown the Derby network listener. This is not a certification issue, but it is an interesting security issue. I think enabling Derby's user authentication system and restricting access to the SystemDatabase DB would be a good idea. Would it work to tie Derby in to Geronimo's existing user authentication system? If yes, perhaps someone can point me to the right classes/module and I'll take a stab at integrating it with a Derby UserAuthenticator. -Tom
Re: Should J2EE apps be using the SystemDatasource ?
Tom McQueeney <[EMAIL PROTECTED]> wrote on 19/04/2005 02:45:25 PM: > Bruce Snyder wrote: > > On 4/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > >>Is the SystemDatasource only intended for the internal use of Geronimo and > >>associated components (e.g. Geronimo's "timertasks" table, ActiveMQ's > >>tables ) and not intended for direct use by J2EE applications? I am > >>guessing some reasons for this could be: > >> > >>* safety - we don't want J2EE apps playing with our internal tables or > >>have any table name conflicts with J2EE apps > >>* performance? > > There is another possible safety issue. From my understanding of the > specs, JSR 151 J2EE.2.5 requires a JDBC database to be accessible from a > client container. To me, that requires or implies a client application > running on a remote machine must be able to access Derby. That means > Derby must be configured to listen on an external network interface, or > Geronimo needs to provide a JDBC listener to delegate to Derby. > > Here are some thoughts. If I'm I'm off base or if these issues already > have been addressed, please let me know. > > o The SystemDatabase configuration sets up Derby to listen only on > localhost. That means external client containers won't be able to access > the JDBC database by connecting directly to Derby. Will this setup pass > certification tests, or is another mechanism provided for remote J2EE > clients to access the database? > Correct, we don't currently allow remote access in the SystemDatabase configuration, but I think the current configuration isn't secure... Here is an excerpt of a mail titled "Securing the Derby Network Server in Geronimo - related to GERONIMO-342" I sent on 27 Jan 05: "Derby's DRDA (Distributed Relational Database Architecture) Network Server by default only listens for connections on the loopback address (which is a good default) and does not have authentication turned on. Therefore on a multiuser O/S this level of security seems inadequate as any user on the localhost could connect to it using the DB2 Universal Connector (specifying any userid and password as it will be ignored by the server) and start creating databases/tables etc. " > o If Derby is set up to listen on 0.0.0.0 or the server's external > interface, Derby should be set up to require authentication to close the > security hole of any client being able to modify any Derby database. +1 > > o The Geronimo J2EE client container could be set up to provide a > DataSource through JNDI that prohibits access to the SystemDatabase. > That would provide some level of protection. But if Derby is listening > on a public interface, requiring client authentication would still be a > good idea. I don't think we should prevent access completely from a remote client to the SystemDatasource, it could be useful to be able to connect to it for support/diagnostic purposes (especially when Geronimo is running on a headless server where you are limited to the tools you can use). It should definately be password protected and the Geronimo installation process should force the user to enter a password, so that we don't have thousands of Geronimos around the world running with default passwords. > > >>Does anyone know of any other tables that will be placed in the > >>SystemDatasource? > >> > >>some notes for future reference... > >> > >>Geronimo's "timertasks" table creation statements are in > >>geronimo\modules\timer\src\java\org\apache\geronimo\timer\jdbc\JDBCWorkerPersistence. > java > >> > >>ActiveMQ's table creation statements are in the getCreateSchemaStatments > >>(..) method in > >>activemq\modules\core\src\java\org\activemq\store\jdbc\adapter\DefaultStatementProvider. > java > > > > > > I agree that we don't want J2EE apps messing with system related > > resources like the SystemDatasource, but I don't know that there is > > any manner in which to scope such resources only for use by the kernel > > or GBean-wrapped components. Is there any such feature? > > > > Bruce > > Derby provides three modes of user authentication: using an LDAP server, > the "BUILTIN" user repository that uses system properties for usernames > and passwords, or providing a custom "UserAuthenticator" class. > > Once authentication is enabled, you can restrict access to Derby's > SystemDatabase by setting the "defaultConnectionMode" property to > "noAccess" or "readOnlyAccess" to limit what outsiders can do to the > database. That would mean Geronimo needs to login to Derby as an > authorized user, or (continue to use?) the embedded JDBC driver, which I > think bypasses security. The following link seems to suggest that security can be used for the embedded database: http://incubator.apache.org/derby/manuals/develop/develop95.html#HDRSII-CSECUR-12392 > > One shortcoming with authorization: the current version of Derby allows > all authenticated users to shutdown Derby if they connect
Re: Connecting to SystemDatabase and create table
I dont know how to do it :-( >From: Dain Sundstrom <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: Connecting to SystemDatabase and create table >Date: Mon, 18 Apr 2005 08:57:12 -0700 > >Katia, > >This is great information. Can you add it to the wiki so others >can find it easily? > >Thanks, > >-dain > >-- >Dain Sundstrom >Chief Architect >Gluecode Software >On Apr 16, 2005, at 5:50 PM, Katia Aresti Gonzalez wrote: > >>Hello! >> >>To connect to the SystemDatabase, and be able to continue with the >>cmp deployment, just follow these steps: (Windows) >> >>1º STEP a folder with these 3 jars inside: >> >>1. db2jcc.jar >>2. db2jcc_license_c.jar >> >>you download from IBM site: >>Derby does not currently provide a network JDBC driver, therefore >>you must download the IBM DB2 Universal Driver: >>http://www-106.ibm.com/developerworks/db2/downloads/jcc/ >> >>3. derbytools.jar >>you get it from the >>http://incubator.apache.org/derby/derby_downloads.html. Just >>download derby, unzip, and there is the tool!!! >> >>2º STEP: Create a derby.bat: >> >>set classpath=%the folder where you have the 3 jars% >>java -cp >>derby.jar;derbynet.jar;derbytools.jar;db2jcc.jar;db2jcc_license_c.jar >>-Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=system >>-Dij.password=manager >>-Dij.protocol=jdbc:derby:net://localhost:1527/ >>org.apache.derby.tools.ij >>pause >> >>This derby.bat goes in the same folder where you have the jars. >> >>3ºSTEP >> >>run the derby.bat, and if everything is ok, you will get in your >>command line: >>ij> >> >>To connect to the SystemDatabase, Geronimo must be running!!! just >>type: >> >>ij> CONNECT 'jdbc:derby:net://localhost:1527/SystemDatabase'; >>ij> create table gente (nombre varchar(50)); >>0 rows inserted/updated/deleted >>thats all!!! >> >>thanks!! >> >>Katia >> >>Acepta el reto MSN Premium: Envía hasta 500 megas diarios de fotos >>desde Hotmail. Descárgalo y pruébalo 2 meses gratis. Recibe ofertas de empleo adaptadas a tu perfil. Introduce tu CV en MSN Empleo.
