Some of the common SSL errors that you run into when connecting to a secure HTTP server with Java
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate - This happens when the server is requesting a client certificate and the client is not presenting a valid certificate. For this you need to configure your local Java Keystore, with a valid client certificate
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target - This indicates that the client does not trust the server. This can be either due to the fact that the Java Trust Store is not configured or the Trust Store does not have the servers certificate. For this, you need to import the Server certificate into the local Java Trust Store.
A quick way to trust the server is to export the servers certificate with Firefox (Here is How) and
When connecting to a secure web service endpoint with an Axis 2 client, there are multiple ways to configure SSL on the client. Basically the client needs to have the public certificate of the server that its trying to connect to. Here are the different ways you can configure the client at runtime.
1. Set the default Java keystore by setting system properties
This will set the keystore for the entire JVM, so every connection emanating from this JVM will use this keystore file to load its certificates
2. Axis 2 uses Commons HTTP client. So you can configure the client directly as follows
Protocol.registerProtocol("https", new Protocol("https", new
CalculatorService service = new CalculatorService("https://localhost:9443/calculatorService);
The CustomSSLSocketFactory can then load the appropriate keystore at runtime. This applies to all HTTPS connection from this Axis2 instance. 3. Create a custom protocol
Protocol.registerProtocol("myhttps", new Protocol("https", new CustomSSLSocketFactory(), 9443));
CalculatorService service = new CalculatorService("myhttps://localhost:9443/calculatorService);
This method will not change the default Protocol Handler for the HTTPS protocol but simply use our CustomSSLSocketFactory when connecting to this particular service (https://localhost: 9443/calculatorService).
4. Manipulate the stub directly by doing
Protocol authProtocol = new Protocol("https", new CustomSSLSocketFactory(), 9443));
This will set the Custom protocol handler directly on the client and does not affect other call outs from different clients/threads in the axis engine. This can be useful when you want to load different certificates for different URL’s.
We are using Canvas LMS but want to use our own existing authentication, so our users don't need a second set of credentials to login to Canvas. I struggled a little bit with this so thought of posting this for reference. To get Canvas LMS working with third party authentication, you really have two options
Host canvas LMS yourself and just plug-in a custom authentication module. Canvas is an open source LMS solution so this should work just fine.
Setup a SAML identity provider (idp) and setup your account in Canvas with SAML authentication
We chose option #2 because we were using a hosted version of Canvas. There is some documentation here on setting up various authentication profiles in Canvas.
We used SimpleSaml as our SAML Identity Provider. SimpleSaml is very easy to setup and comes pre-packaged with multiple authentication providers (local text based basic authentication, OpenId etc.). Our plan was to write a custom authentication provider within SimpleSaml which would leverage our own custom username/password database.
To set all this up just do the following.
Canvas for Saml authentication. If you are testing with a local deployment of Canvas, edit config/saml.yml and add the following
development: entity_id: "http://localhost:3000/saml2" tech_contact_name: "Administrator" tech_contact_email: "
" encryption: xmlsec_binary: /usr/local/bin/xmlsec1 private_key: /Applications/XAMPP/simplesamlphp/cert/server.pem certificate: /Applications/XAMPP/simplesamlphp/cert/server.crt
Configure you Canvas account (super user account under which all others users are created) to use SAML authentication. Here is a screenshot of our configuration
Install SimpleSaml and enable SAML authentication by editing simplesaml/config/config.php and declaring
'enable.saml20-idp' = true,
Edit simplesaml/config/authsources by setting up an appropriate authentication source. For testing we just used a in-memory Map of username-passwords as follows
'example-userpass' = array( 'exampleauth:UserPass', '
:test' = array( 'uid' = array('
'), 'email' = '
', 'eduPersonAffiliation' = array('member', 'student'), ), ),
Edit simplesaml/metadata/saml20-sp-remote.php and set Canvas as a remote Service Provider (Canvas deploys the SAML service provider by default)
I used the certificates that came with SimpleSaml. Just calculate the MD5 fingerprint of the certificate and use it to configure canvas (step #1). This establishes "trust" between Canvas and SimpleSaml
That should be it. Now when you try and go to the Canvas homepage at http://localhost:3000, it will forward you to the following Screen
Once you login here (using the credentials in the example-userpass authentication provider), you should be logged in to Canvas automatically. Remember the test user (
) should already exist in Canvas and have a login id of
I will post a follow up on creating a custom authentication provider in SimpleSaml....stay tuned
I ran into this issue with using MySQL and Postgres drivers with a Ruby On Rails application on Mac OS X 10.7.3 (Lion). When trying to install the RoR dependency using "gem", I was getting the following error (same for MySQL)
$ sudo gem install pg Buildingnative extensions.This could take a while... ERROR:Error installing pg: ERROR:Failed to build gem native extension.
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb checking for pg_config... yesUsing config values from/Library/PostgreSQL/8.3/bin/pg_config checking for libpq-fe.h... yes checking for libpq/libpq-fs.h... yes checking forPQconnectdb()in-lpq...no checking forPQconnectdb()in-llibpq...no checking forPQconnectdb()in-lms/libpq...no Can't find the PostgreSQL client library (libpq) *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options.
Started a new gig last week. One of the first things I had to go through was a 45 minute training session on ClearCase. In case you don't know what it is (i had a vague idea till a few weeks ago), its a Version Control System (VCS) from IBM. After going through the training and playing around with ClearCase for a couple of day, its confusing why anyone in their right mind would pay money to use an inferior product. Compared to the simplicity of CVS, SVN (and perhaps GIT), ClearCase seems rather complicated for what it is trying to do.
The main difference between ClearCase and SVN/CVS, is that ClearCase creates a "virtual view" (in case of Windows, a mapped drive) to the repository. Any changes you make to this view, is actually being done on the ClearCase server. This makes it a bad tool for collaborative change management and mandates that each developer create their own "virtual view" in ClearCase. As opposed to SVN, where you basically create a local snapshot of what is in the repository and then you are free to make changes to your local snapshot without affecting other people working on the same repository. This basic difference in makes a huge difference in how you interact with the VCS using ClearCase vs SVN/CVS.
This makes it necessary for EACH developers to create their own personal branches to work on, and to periodically sync this branch back to trunk (or another release branch). This explains why at a previous assignment the CM team presented a similar approach, but using SVN, where a release branch was created on Day 1, and each developer had their own SVN branch to work on. When I questioned this approach as being unnecessarily complex, I was told that this was "Standard CM practice in the industry" :-(
In my opinion SVN is clearly a superior product because
Has less overhead for developers in setting up, checking in and merging their changes
(SVN) Needs a light weight client and is easily and more readily integrated into a variety of tools - IDE's, Continuous Integration servers etc.
ClearCase is SLOW and as the repository grows, it gets slower still. SVN on the other hand has no performance degradation over time or with increased actvity
ClearCase considers each file as an atmoic check-in, which means when checking in a bunch of files (which is often the case), the check-in can fail in between with no way to automatically revert the partial check-in
This might be minor for some but it seems like a HUGE deal to me. With the amount of interaction you have with the VCS on multi developer software projects, even minor inconveniences such as these (above) seem to have a big impact on productivity. Why is IBM sticking with this antiquated technology? Why is it in such widespread use? Have i missed some major advantages of ClearCase?