Kerberos

asmr_anders_sonderbe · 9 January 2012 13:48

Hi,

I am trying to run the latest version of the Jalview applet in a single-sign-on (SSO) environment using Kerberos authentication. I have setup my Apache web server to use kerberos authentication when a user accesses the directory, where these files are located:

-rw-r--r-- 1 root root 436094 2012-01-06 15:06 jalviewApplet.jar
-rw-r--r-- 1 root root 623 2012-01-06 15:09 jalviewtest.aln
-rw-r--r-- 1 root root 448 2012-01-06 15:28 jalviewtest.html

The user can load the html file and the applet just fine with SSO, but when the applet tries to access the .aln file a new login prompt is displayed by the applet. Is there any chance that the applet can reuse the kerberos authentication session so the user does not need to provide credentials again?

My applet tag is listed below.

Thank you for any help!

Best regards

Anders

jalviewcrowdadmin · 9 January 2012 16:25

Hello Anders.

I am trying to run the latest version of the Jalview applet in a single-sign-on (SSO) environment using Kerberos authentication. I have setup my Apache web server to use kerberos authentication when a user accesses the directory, where these files are located:

-rw-r--r-- 1 root root 436094 2012-01-06 15:06 jalviewApplet.jar
-rw-r--r-- 1 root root 623 2012-01-06 15:09 jalviewtest.aln
-rw-r--r-- 1 root root 448 2012-01-06 15:28 jalviewtest.html

The user can load the html file and the applet just fine with SSO, but when the applet tries to access the .aln file a new login prompt is displayed by the applet. Is there any chance that the applet can reuse the kerberos authentication session so the user does not need to provide credentials again?

I'm pretty sure there is a way of doing this, but I'm not familiar enough with the JAAS architecture to know the solution without some digging around.

I've opened a bug here: http://issues.jalview.org/browse/JAL-1038

What I think is going on is as follows:
1. JalviewLite is being launched with a properly configured security context provided by the browser
2. It's trying to use a generic URL data retrieval method (URL.openStream()) to retrieve data from the server.
=> Instead of reusing the existing context, Java seems to be wanting to create a new security context for the connection.

Could you confirm this is happening by sending me the output from the java console when you put in an incorrect password ? (it would be even better if you were using unobfuscated debug version of jalviewLite at http://www.jalview.org/examples/debug/jalviewApplet.jar - so the line numbers make sense).

Jim.
ps. One other thing: you might be able to get around the problem simply by adding the data you are loading into the applet to its classpath. If you make a zip containing the data, and add it to the 'archive' tag like 'jalviewApplet.jar,mydata.zip', the applet should then load the data from mydata.zip. You'll be able to see that happening in the debug output on the console.

···

On 09/01/2012 13:48, ASMR (Anders Sønderberg Mortensen) wrote:

asmr_anders_sonderbe · 10 January 2012 07:50

Hi Jim and others,

Thanks for the prompt reply - I appreciate it! Your description of what is happening sounds correct. The Java console output is listed below with the debug .jar. It appears to be using basic authentication scheme which is not what I execpted. We have already been talking about getting around with the problem by putting the .aln file in a place accessible to everybody, but we are not too happy about doing it that way.

Thanks -

--Anders

basic: Starting applet teardown
Applet panel0 stop().
Applet panel0 destroy().
basic: Finished applet teardown
basic: Added progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@fc1dce
basic: Plugin2ClassLoader.addURL parent called for http://davinci/kerb_test/jalview/jalviewApplet.jar
basic: Applet loaded.
basic: Applet resized and added to parent container
basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 169575 us, pluginInit dt 454179971 us, TotalTime: 454349546 us
Applet context is 'class sun.plugin2.applet.Plugin2Manager$AppletContextImpl'
Applet has Javascript callback support.
JalviewLite Version 2.7
Build Date : 27 September 2011
basic: Applet initialized
basic: Removed progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@fc1dce
basic: Applet made visible
basic: Starting applet
basic: completed perf rollup
basic: Applet started
basic: Told clients applet is started
security: Accessing keys and certificate in Mozilla user profile: null
Clear classloader cache ... completed.
basic: Starting applet teardown
Applet panel1 stop().
Applet panel1 destroy().
basic: Finished applet teardown
basic: Added progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@b408b0
basic: Plugin2ClassLoader.addURL parent called for http://davinci/kerb_test/jalview/jalviewApplet.jar
network: Cache entry found [url: http://davinci/kerb_test/jalview/jalviewApplet.jar, version: null] prevalidated=false/0
network: Connecting http://davinci/kerb_test/jalview/jalviewApplet.jar with proxy=DIRECT
network: Connecting http://davinci:80/ with proxy=DIRECT
network: Firewall authentication: site=davinci/172.19.1.52:80, protocol=http, prompt=Bioweb login, scheme=basic
network: Connecting http://davinci/kerb_test/jalview/jalviewApplet.jar with proxy=DIRECT
network: Connecting http://davinci:80/ with proxy=DIRECT
network: Firewall authentication: site=davinci/172.19.1.52:80, protocol=http, prompt=Bioweb login, scheme=basic

···

-----Original Message-----
From: Jim Procter [mailto:foreveremain@gmail.com] On Behalf Of Jim Procter
Sent: 9. januar 2012 17:26
To: ASMR (Anders Sønderberg Mortensen)
Cc: jalview-discuss@jalview.org
Subject: Re: [Jalview-discuss] Kerberos

Hello Anders.

On 09/01/2012 13:48, ASMR (Anders Sønderberg Mortensen) wrote:

I am trying to run the latest version of the Jalview applet in a single-sign-on (SSO) environment using Kerberos authentication. I have setup my Apache web server to use kerberos authentication when a user accesses the directory, where these files are located:

-rw-r--r-- 1 root root 436094 2012-01-06 15:06 jalviewApplet.jar
-rw-r--r-- 1 root root 623 2012-01-06 15:09 jalviewtest.aln
-rw-r--r-- 1 root root 448 2012-01-06 15:28 jalviewtest.html

The user can load the html file and the applet just fine with SSO, but when the applet tries to access the .aln file a new login prompt is displayed by the applet. Is there any chance that the applet can reuse the kerberos authentication session so the user does not need to provide credentials again?

I'm pretty sure there is a way of doing this, but I'm not familiar enough with the JAAS architecture to know the solution without some digging around.

I've opened a bug here: http://issues.jalview.org/browse/JAL-1038

What I think is going on is as follows:
1. JalviewLite is being launched with a properly configured security context provided by the browser 2. It's trying to use a generic URL data retrieval method
(URL.openStream()) to retrieve data from the server.
=> Instead of reusing the existing context, Java seems to be wanting to create a new security context for the connection.

Could you confirm this is happening by sending me the output from the java console when you put in an incorrect password ? (it would be even better if you were using unobfuscated debug version of jalviewLite at http://www.jalview.org/examples/debug/jalviewApplet.jar - so the line numbers make sense).

Jim.
ps. One other thing: you might be able to get around the problem simply by adding the data you are loading into the applet to its classpath. If you make a zip containing the data, and add it to the 'archive' tag like 'jalviewApplet.jar,mydata.zip', the applet should then load the data from mydata.zip. You'll be able to see that happening in the debug output on the console.

jalviewbugreporter · 10 January 2012 12:05

Thanks for the output, Anders.

The Java console output is listed below with the debug .jar. It appears to be using basic authentication scheme which is not what I execpted.

hmm. This very much depends on the kind of SSO system you are using I suspect, though I'm far from being an expert on this! From the output you sent, however, it looks like the applet doesn't even get as far as generating debug messages concerning what its doing before the authentication dialog is shown.

We have already been talking about getting around with the problem by putting the .aln file in a place accessible to everybody, but we are not too happy about doing it that way.

That's quite understandable!

I'm actually having trouble recreating the situation you are observing, and that I described in my previous email. If I stage an applet behind a Basic HTTPAuth server, then I get prompted once after the java console appears, and providing I authenticate correctly, I don't see another authentication box for the lifetime of that java plugin (ie until the console disappears), and all the data loads in fine. This isn't what you've described, and I'm very pressed for time at the moment, so I probably won't be able to replicate the SSO setup you have in the immediate future.

If the Jalview applet is actually launching, then you might be able to try a different approach and pass the data to Jalview via javascript after getting it from the SSO-authed server. There's a very simple example here:
http://www.jalview.org/examples/javascriptLaunch.html

If that does the trick, then you should be able to specify all the other default parameters (defaultColour, etc) in the applet tag and the only difference will be that a javascript button will be shown rather than jalviewLite's own button.

Jim.
ps. I'd like to resolve this in the future - since there is increasing interest in having Jalview play nice with secure data sources. Would you mind adding some comments about the apache config and browser combinations you are experiencing the problem with on the bug report ? (its at http://issues.jalview.org/browse/JAL-1038 )
.. I'll then try and get around to setting up my own system so I (or someone else!) can experiment with making the applet aware of its security context.

···

On 10/01/2012 07:50, ASMR (Anders Sønderberg Mortensen) wrote: