Skip to content
Permalink
Browse files
JUDDI-920 updating documentation
JUDDI-906 adding additional 'just in case' code to assist with cleanup
  • Loading branch information
spyhunter99 committed Jan 17, 2015
1 parent 86d58ae commit 53d6f2d2c1b8322c6382c154e4fa32ab38eb5dd5
Showing 3 changed files with 42 additions and 10 deletions.
@@ -12,6 +12,8 @@ jUDDI Server (Tomcat) - This assumes you are using the jUDDI server bundled with
- Edit `webapps/juddiv3/WEB-INF/config.properties` and change the port numbers for "securityurl" and "juddipapi".
- Edit `webapps/juddi-gui/META-INF/config.properties` and change the port numbers for all of the URLs listed.

If these changes are made before jUDDI has been started for the first time, then no further action is required. If jUDDI has been previously started, you'll need to either A) update the URL information for the Node's root business entity URLs or B) turn on "Seed Always" in the juddiv3.xml file to auto update the changes.

=== Administering Users and Access Control

As of version 3.2, jUDDI Authentication is handled from two perspectives, administrator and end user access.
@@ -195,20 +197,24 @@ juddi/auth/securityDomain=java:/jaas/other
----
The juddi/auth/authenticator/class property plugs the JbossAuthenticator class into the jUDDI the Authenticator framework. The juddi/sercuityDomain, configures the JBossAuthenticator class where it can lookup the application server's security domain, which it will use to perform the authentication. Note that JBoss creates one security domain for each application policy element on the `$JBOSS_HOME/server/default/conf/login-config.xml` file, which gets bound to the server JNDI tree with name java:/jaas/<application-policy-name></application-policy-name>. If a lookup refers to a non existent application policy it defaults to a policy named other.

===== Contained Based Authentication
===== Container Based Authentication

Certain security configurations may use HTTP based authentication. In this scenario, jUDDI simply trust's that the container will authenticate the user via some mechanism and uses that username for interactions with jUDDI. To configure this setup, use the following configuration settings in juddiv3.xml:
----
juddi/auth/authenticator/class=org.apache.juddi.auth.HTTPContainerAuthenticator
juddi/auth/authenticator@useAuthToken=false
----

In addition, you'll have to make whatever changes necessary to the juddiv3.war/WEB-INF/web.xml file in order to use the chosen authentication mechanism. See your appliation server's documentation for details on this.


===== Authentication by Proxy
===== Authentication by Proxy (HTTP Header)

Certain security configurations that enforce authentication before requests come to the web application, such as via Apache HTTPD or a reverse SSL proxy. In these cases, the proxy provide authenticates the user, then passes along the user's identity via a HTTP header. To configure this setup, use the following configuration settings in juddiv3.xml:
Certain security configurations that enforce authentication before requests come to the web application, such as via Apache HTTPD or a reverse SSL proxy. In these cases, the proxy provided authenticates the user, then passes along the user's identity via a HTTP header. To configure this setup, use the following configuration settings in juddiv3.xml:
----
juddi/auth/authenticator/class=org.apache.juddi.auth.HTTPHeaderAuthenticator
juddi/auth/authenticator/header=(Some HTTP Header)
juddi/auth/authenticator@useAuthToken=false
----

[[ConfiguringDatabaseConnections]]
@@ -20,6 +20,7 @@ IMPORTANT: When referring to configuration 'properties', we are really referenci
|_juddi/auth/token/Timeout_ |Time in minutes to expire tokes after inactivity.|N |_15_
|_juddi/auth/token/Expiration_ |As of 3.1.5 Duration of time for tokens to expire, regardless of inactivity.|N |_15_
|_juddi/auth/token/enforceSameIPRule_ |As of 3.2 This setting will enable or disable the auth token check to ensure that auth tokens can only be used from the same IP address that they were issued to..|N |_true_
|_juddi/auth/authenticator@useAuthToken | Indicates that the authenticator is use requires a UDDI auth token. Set to false when using HTTP based authenticators | N | _true_

|===========================================================================================

@@ -466,7 +466,7 @@ public void testMultiNodeBusinessCustodyTransfer() throws Exception {
* @throws Exception
*/
@Test
// @Ignore
// @Ignore
public void testReplicationTModelBusinessPublisherAssertionAddDelete() throws Exception {
Assume.assumeTrue(TckPublisher.isReplicationEnabled());
Assume.assumeTrue(TckPublisher.isJUDDI());
@@ -479,7 +479,7 @@ public void testReplicationTModelBusinessPublisherAssertionAddDelete() throws Ex

TModel saveMaryPublisherTmodel = maryTModelNode1.saveMaryPublisherTmodel(maryTokenNode1);
samTModelNode2.saveSamSyndicatorTmodel(samTokenNode2);

BusinessEntity saveMaryPublisherBusiness = maryBizNode1.saveMaryPublisherBusiness(maryTokenNode1);

// TModel saveSamSyndicatorTmodel = samTModelNode2.saveSamSyndicatorTmodel(samTokenNode2);
@@ -980,7 +980,9 @@ public void testReplicationServiceBindingAddRemove() throws Exception {
// TckCommon.PrintMarker();

} finally {
/*try {
TckCommon.PrintMarker();
logger.fatal("The test failed, attempting to clean up the business and tModels");
try {
DeleteBusiness db = new DeleteBusiness();
db.setAuthInfo(samTokenNode2);
db.getBusinessKey().add(TckBusiness.SAM_BUSINESS_KEY);
@@ -994,8 +996,6 @@ public void testReplicationServiceBindingAddRemove() throws Exception {
logger.info("Waiting for the update...");
try {
tModelDetail = inquiryMary.getBusinessDetail(findTModel);
// JAXB.marshal(tModelDetail, System.out);
//
} catch (Exception ex) {
logger.warn(ex.getMessage());
tModelDetail = null;
@@ -1014,8 +1014,7 @@ public void testReplicationServiceBindingAddRemove() throws Exception {

} catch (Exception ex) {
ex.printStackTrace();
Assert.fail(ex.getMessage());
}*/
}
resetTmodels();

}
@@ -1215,4 +1214,30 @@ private void waitForTModelAdminDeletion(String tModelKey, UDDIInquiryPortType in

}

/**
* If the same key is created at two nodes before the replication change
* record has been distributed, it's possible for the same record to be
* owned by two different nodes. After a short period of time, both
* records should be rejected
*
* <a href="http://www.uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908178">7.3.9</a>
* for more info on collision detection
*
* @throws Exception
*/
@Test
@Ignore
public void replicationConflictMaintainOwership() throws Exception {
try {
resetTmodels();

maryTModelNode1.saveMaryPublisherTmodel(maryTokenNode1);
samTModelNode2.saveMaryPublisherTmodel(samTokenNode2);

} finally {
resetTmodels();
}

}

}

0 comments on commit 53d6f2d

Please sign in to comment.