Watched for a second time the IMAX movie Mystery of the Nile on Bluray.
Out of five IMAX blurays I own this is one of my favorites.
I like the raft journey from Lake Tana in Ethiopia to the mouth of the Nile at Alexandria.
They visit some amazing sites like rock monolith churches in Lalibela, the Meroe pyramids in Sudan where the Kingdom of Kush existed around 1500 B.C., and Luxor, Egypt.
Doing a third to half of what they rafted or maybe puddle jumping with a plane from some of the highlights would be quite cool.
Sunday, September 26, 2010
Friday, September 24, 2010
digital certificates, keys, and message validation
I've been exploring digital certificates a little more in depth this week. They're basically analogous to a "drivers license" in the digital domain.
A drivers license basically allows you to validate who you are (e.g, a face to a name, your age, etc...) to an authority who would like to authentiate and authorize you (maybe a policeman or door man) based on their trust in the authority that issued your license; usually the DMV. Because the license is hard to duplicate and has a certain format (being laminated, has your photo, and a magnetic strip and/or watermarks) the authority has provided strong backing validation when you present your license to third parties like a policeman or other authority figures. Therefore trust and authentication are - hopefully - maintained when you use a license.
An equivalent type of license that validates who you are and is used over the Internet is called a Digital Certificate. Although it might not validate your age, it will help validate a message or document that you might send along with it to the person you are sending it to.
Obviously, drivers licenses offer a lot of private information when you view them: photo, age, address, etc... You keep your license information private by keeping it in your wallet. Digital certificates don't have the same information. They do provide some identity information of who the individual or server is just like a drivers license, but unlike a drivers license a digital certificate provides a mechanism to encypt an exchange (aka transaction) between a client and a server; and itself can be encrypted too.
And since sensitive transactions happen over the Internet, where a sophisticated individual can intercept your credit card information, encryption needs to happen for almost all stages of a transaction (or depending on your level of need).
In this case, a digital certificate is used by a server to authenticate who they are to a client browser. Amazon, for example, sends you a digital certificate to authenticate itself to your browser and then encrypts your shopping cart transaction, etc...
A drivers license basically allows you to validate who you are (e.g, a face to a name, your age, etc...) to an authority who would like to authentiate and authorize you (maybe a policeman or door man) based on their trust in the authority that issued your license; usually the DMV. Because the license is hard to duplicate and has a certain format (being laminated, has your photo, and a magnetic strip and/or watermarks) the authority has provided strong backing validation when you present your license to third parties like a policeman or other authority figures. Therefore trust and authentication are - hopefully - maintained when you use a license.
An equivalent type of license that validates who you are and is used over the Internet is called a Digital Certificate. Although it might not validate your age, it will help validate a message or document that you might send along with it to the person you are sending it to.
Obviously, drivers licenses offer a lot of private information when you view them: photo, age, address, etc... You keep your license information private by keeping it in your wallet. Digital certificates don't have the same information. They do provide some identity information of who the individual or server is just like a drivers license, but unlike a drivers license a digital certificate provides a mechanism to encypt an exchange (aka transaction) between a client and a server; and itself can be encrypted too.
And since sensitive transactions happen over the Internet, where a sophisticated individual can intercept your credit card information, encryption needs to happen for almost all stages of a transaction (or depending on your level of need).
In this case, a digital certificate is used by a server to authenticate who they are to a client browser. Amazon, for example, sends you a digital certificate to authenticate itself to your browser and then encrypts your shopping cart transaction, etc...
Tuesday, September 21, 2010
New to Cobertura
Finally got to use Cobertura. I initially started working with the 1.9 build but then decided to use 1.9.4.1, which worked quite well. If I can, I'll always use the latest version.
Took me about a week of experimenting with it - in addition to other duties - to get a handle on the process for creating accurate Cobertura coverage reports.
Some of the things that got me during the initial week were: 1) 100% coverage reports (when I knew there wasn't 100% coverage), 2) using the ant tasks effectively, 3) having an incomplete cobertura.ser be generated by JBoss (in addition to a cobertura.ser.lock file), and 4) having cobertura work with my Eclipse instance where I'd run my junit/htmlunit tests.
For #1 I had to merge the originally created cobertura.ser files (when I instrumented the JAR files I needed) with the one created when running JBoss and the htmlunit tests through the Eclipse IDE. I ultimately used the cobertura ANT task cobertura-instrument to explicitly create a ser datafile while instrumenting, and then used cobertura-merge to merge the ser files together after running my tests.
For #2, I got to know the Ant Task Reference page from the cobertura sourceforge page, which was helpful.
For #3, I'd get an incomplete ser file created after running my htmlunit test cases against a running JBoss server with my deployed application. I'd always have a cobertura.ser.lock file too. One thing I noted was if I had been running multiple test suites after each other and data.zip files would be created. I would try to delete old ones and that seemed to solve most of my lock file issues.
For #4, I had to have Eclipse Helios with the development packages, along with the test packages I was using to test the application's admin interface. I was able to run suite test classes that would have up to 700 tests by running as Junit, and of course, I made sure JBoss was up and running with my deployed application; either created from my dev folder using a maven command or getting a build from Hudson. Either way worked.
Took me about a week of experimenting with it - in addition to other duties - to get a handle on the process for creating accurate Cobertura coverage reports.
Some of the things that got me during the initial week were: 1) 100% coverage reports (when I knew there wasn't 100% coverage), 2) using the ant tasks effectively, 3) having an incomplete cobertura.ser be generated by JBoss (in addition to a cobertura.ser.lock file), and 4) having cobertura work with my Eclipse instance where I'd run my junit/htmlunit tests.
For #1 I had to merge the originally created cobertura.ser files (when I instrumented the JAR files I needed) with the one created when running JBoss and the htmlunit tests through the Eclipse IDE. I ultimately used the cobertura ANT task cobertura-instrument to explicitly create a ser datafile while instrumenting, and then used cobertura-merge to merge the ser files together after running my tests.
For #2, I got to know the Ant Task Reference page from the cobertura sourceforge page, which was helpful.
For #3, I'd get an incomplete ser file created after running my htmlunit test cases against a running JBoss server with my deployed application. I'd always have a cobertura.ser.lock file too. One thing I noted was if I had been running multiple test suites after each other and data.zip files would be created. I would try to delete old ones and that seemed to solve most of my lock file issues.
For #4, I had to have Eclipse Helios with the development packages, along with the test packages I was using to test the application's admin interface. I was able to run suite test classes that would have up to 700 tests by running as Junit, and of course, I made sure JBoss was up and running with my deployed application; either created from my dev folder using a maven command or getting a build from Hudson. Either way worked.
Tuesday, August 24, 2010
Creating keystore for Tomcat 6
I've been training on Ping Identity's Ping Federate server the last two weeks. This week I'm setting up separate Tomcat servers to interact with the Ping Federate servers; on both the identity and service provider servers. Before, I hosted the quickstart apps on the same server instance as Ping Federate.
To setup SSL with Tomcat I needed to edit the server.xml file under the conf directory and then create a keystore file that Tomcat will use to verify trusted certificates sent from the federated servers.
The initial command I ran was:
>>>> : keytool -genkey -alias amf -keyalg RSA -keystore tomcat.keystore [-file 111C353A88F.crt]
The last part of the command with the -file command line argument wasn't needed. I basically created a keystore file named tomcat.keystore and a new self-signed certificate where the Java keytool prompted me with some questions listed below:
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Andrew Fernandez
What is the name of your organizational unit?
[Unknown]: Engineering
What is the name of your organization?
[Unknown]: Ping Identity
What is the name of your City or Locality?
[Unknown]: Denver
What is the name of your State or Province?
[Unknown]: CO
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Andrew Fernandez, OU=Engineering, O=Ping Identity, L=Denver, ST=CO, C=US correct?
[no]: yes
Enter key password for
(RETURN if same as keystore password):
After this I verified what was in my keystore using this command:
>>>> : keytool -list -v -keystore tomcat.keystore
Since I didn't yet have the certificate from the federate side I then ran this command, making sure I had the *.crt file I needed to place in the keystore in the same directory:
>>>>> : keytool -import -trustcacerts -alias amf2 -file 111C353A88F.crt -keystore tomcat.keystore
Finally I use export the base certificate from Tomcat and import into my Federated server
>>>>> : keytool -exportcert -alias amf -file amfIDP -keystore tomcat.keystore
Where -alias is what the certificate goes by in the keystore file, -file is what I want to call the exported certifacate, and -keystore the actually keystore where I'll be getting the certifcate to export from.
Deletion is pretty straighforward:
>>>>> : keytool -delete -alias amf -keystore tomcat.keystore
Just specify -delete, -alias the certificate you want to delete, and the keystore you want to delete from
To setup SSL with Tomcat I needed to edit the server.xml file under the conf directory and then create a keystore file that Tomcat will use to verify trusted certificates sent from the federated servers.
The initial command I ran was:
>>>> : keytool -genkey -alias amf -keyalg RSA -keystore tomcat.keystore [-file 111C353A88F.crt]
The last part of the command with the -file command line argument wasn't needed. I basically created a keystore file named tomcat.keystore and a new self-signed certificate where the Java keytool prompted me with some questions listed below:
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Andrew Fernandez
What is the name of your organizational unit?
[Unknown]: Engineering
What is the name of your organization?
[Unknown]: Ping Identity
What is the name of your City or Locality?
[Unknown]: Denver
What is the name of your State or Province?
[Unknown]: CO
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Andrew Fernandez, OU=Engineering, O=Ping Identity, L=Denver, ST=CO, C=US correct?
[no]: yes
Enter key password for
(RETURN if same as keystore password):
After this I verified what was in my keystore using this command:
>>>> : keytool -list -v -keystore tomcat.keystore
Since I didn't yet have the certificate from the federate side I then ran this command, making sure I had the *.crt file I needed to place in the keystore in the same directory:
>>>>> : keytool -import -trustcacerts -alias amf2 -file 111C353A88F.crt -keystore tomcat.keystore
Finally I use export the base certificate from Tomcat and import into my Federated server
>>>>> : keytool -exportcert -alias amf -file amfIDP -keystore tomcat.keystore
Where -alias is what the certificate goes by in the keystore file, -file is what I want to call the exported certifacate, and -keystore the actually keystore where I'll be getting the certifcate to export from.
Deletion is pretty straighforward:
>>>>> : keytool -delete -alias amf -keystore tomcat.keystore
Just specify -delete, -alias the certificate you want to delete, and the keystore you want to delete from
Thursday, August 12, 2010
Mac OS X differences from Windows
Having started the new job at Ping Identity I now have a MacBook Pro with OS X.
I've had to get used to two notable differences:
1) Window resizing on the OS X is only on the lower right-hand corner versus Windows XP which can be on the bottom and sides too.
2) Copying and pasting in the Finder (which is the equivalent of Windows Explorer) is not like Windows. If I chose a file and copy it I cannot just highlight a new directory and choose paste. I actually have to enter into the directory and paste making sure the dialog title for the Finder lists the correct directory where I want to paste.
At least that's what works for me without any special changes to the OS.
I've had to get used to two notable differences:
1) Window resizing on the OS X is only on the lower right-hand corner versus Windows XP which can be on the bottom and sides too.
2) Copying and pasting in the Finder (which is the equivalent of Windows Explorer) is not like Windows. If I chose a file and copy it I cannot just highlight a new directory and choose paste. I actually have to enter into the directory and paste making sure the dialog title for the Finder lists the correct directory where I want to paste.
At least that's what works for me without any special changes to the OS.
Tuesday, July 27, 2010
Web services WSDLs and SOAP bindings
I've been testing web services for 4 years now.
Sometimes it's good to be reminded of the basics when you're explaining JAX-RPC or JAX-WS web services.
Ultimately, when you specify RPC or documental literal wrapped you're stating how the message will be translated to the SOAP envelope that is transmitted over the wire (AKA internet).
In the WSDL you specify the binding or what kind of translation you want in the binding node of the WSDL.
Then that style is used when the message is sent inside the SOAP envelope; specifically the SOAP body.
This IBM article states it well in the first paragraph.
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Sometimes it's good to be reminded of the basics when you're explaining JAX-RPC or JAX-WS web services.
Ultimately, when you specify RPC or documental literal wrapped you're stating how the message will be translated to the SOAP envelope that is transmitted over the wire (AKA internet).
In the WSDL you specify the binding or what kind of translation you want in the binding node of the WSDL.
Then that style is used when the message is sent inside the SOAP envelope; specifically the SOAP body.
This IBM article states it well in the first paragraph.
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Friday, June 18, 2010
Handler Chains: New schema namespace and root node
There's been a change in what is accepted for a handler chain XML file within OEPE, and possibly the WLS runtime libraries.
It used to be accepted to use http://www.bea.com/ns/weblogic/90" for the default namespace but you'll need to start using: java.sun.com/xml/ns/javaee
Also the root node needed for handler chain files needs to be: handler-chains instead of the old weblogic-wsee-clientHandlerChain.
Just to be clear here is an old example file:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-wsee-clientHandlerChain
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</weblogic-wsee-clientHandlerChain>
And the newer one:
<?xml version="1.0" encoding="UTF-8"?>
<handler-chains
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</handler-chains>
It used to be accepted to use http://www.bea.com/ns/weblogic/90" for the default namespace but you'll need to start using: java.sun.com/xml/ns/javaee
Also the root node needed for handler chain files needs to be: handler-chains instead of the old weblogic-wsee-clientHandlerChain.
Just to be clear here is an old example file:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-wsee-clientHandlerChain
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</weblogic-wsee-clientHandlerChain>
And the newer one:
<?xml version="1.0" encoding="UTF-8"?>
<handler-chains
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</handler-chains>
Subscribe to:
Posts (Atom)