It appears that Firefox has a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=57342) that corrupts the downloading of .gz files (it attempts to uncompress and then recompress them). What you actually get on disk is a file that has been gzipped twice.

So, to work around the problem:

a)
gunzip Apache-CrowdAuth-0.03.tar.gz followed by
tar xzvf Apache-CrowdAuth-0.03.tar

(note the 'z' in the arguments to tar)

b) use wget instead

wget http://confluence.atlassian.com/download/attachments/9961902/Apache-CrowdAuth-0.03.tar.gz

I was not able to unpack the Apache-Crowd Auth 0.03 tar archive using tar version 1.13.25 on SuSE enterprise 9.3.

gunzip Apache-CrowdAuth-0.03.tar.gz followed by
tar xvf Apache-CrowdAuth-0.03.tar

resulted in the following error:

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors

Initial version complete.

File bugs as new issues.

The latest version of the module (0.03) fixes this spurious "CrowdAuth: Failed to authenticate principal " error (application token was being cached incorrectly).

Additionally, I'm seeing the following error in the nagios logs:

[Tue Feb 06 15:36:52 2007] [warn] [client 203.14.171.190] CrowdAuth: Failed to authenticate principal : soap:Server:Invalid application client., referer: https://nagios.atlassian.com/nagios/cgi-bin/status.cgi?hostgroup=all&style=grid
[

However the login works.

I've got this working with our nagios server. It involved a lot of work for Contegix as RHEL 3 doesn't support mod-perl2.

Probably the 'correct' thing to do is to break most of the CrowdAuth stuff out into a standalone module (that could be uploaded to CPAN) and then just wrapper it in mod_perl1/2 modules as needed.

Updated the website with the Perl scripts for testing:

http://confluence.atlassian.com/display/CROWD/Integrating+Crowd+with+Apache

After our review meeting here are the notes/comments we have:

• Will use PERL.
• Test / Work on the following platforms:
  • Ubuntu
  • Windows Server 2003
  • Redhat (latest stable)
  • Debian (latest stable)
• Apache 2.0 and greater.
• Subversion 1.2 and greater.

Group security restrictions will be left to the subversion configuration file.

Here is updated documentation for the SOAP service: http://confluence.atlassian.com/display/CROWD/SOAP+API

Interesting article on how Apache 2 can be hooked up to Java and communicate with whatever you want.

http://www.howtoforge.com/apache2_authentication_mssql2000

An alternative way to provide Apache authentication would be to support pluggable SSO tokens in the crowd webapp then utilize CAS modules (or maybe Pubcookie). Then you would get mature Apache authentication modules out of the box. You would just need the Crowd login server to be able to generate CAS compliant SSO tokens. And you would need to provide a thin CAS service endpoint that handles validation requests from the CAS Apache module and converts them to Crowd soap calls.

You might find its less work to provide CAS compliance in the CROWD app than to write a new Apache c++ module. And you will automatically find a whole new set of applications can integrate with CROWD automatically..