Dependency Graph

View IssueRelationship GraphVerticalShow Summary
Dependency Graph
related to related to child of child of duplicate of duplicate of

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001192SOGoBackend Generalpublic2011-03-17 06:242014-03-06 09:45
Reporteramaramrahul Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
Status newResolutionopen 
Product Version1.3.5 
Summary0001192: Ability to use normal SOGo Authentication with SOGoTrustProxyAuthentication=YES
Description

When I set SOGoTrustProxyAuthentication=YES in /home/sogo/GNUstep/Defaults/.GNUstepDefaults and enable proxy authentication in apache2, it works fine. But if I disable proxy authentication in apache2 leaving SOGoTrustPRoxyAuthentication=YES as it is, I get the message, "Unauthorized" whenever I access SOGo URL.

The reason I need SOGo to work even with apache2 proxy authentication disabled is because I have two apache2 frontend servers running. One is used for connecting via thunderbird and uses GSSAPI authentication (which currently is only possible using Apache2 authentication). The other apache2 frontend is used for the regular SOGo webclient. And for the webclient, popping up browser based prompts for username and password is not clean.

Therefore I would like to know if the following is possible i.e. setting SOGoTrustProxyAuthentication=YES and still using the normal SOGo authentication in webclient.

TagsNo tags attached.

Relationships

Relationship GraphDependency Graph
related to 0001113 new Kerberos GSSAPI authentication with Apache2 Frontend does not work 

Activities

wsourdeau

wsourdeau

2011-03-17 16:48

viewer   ~0002268

The cleanest solution would probably be to implement kerberos authentication in SOGo with a fallback on weblogin. Would you like to sponsor this?
amaramrahul

amaramrahul

2011-03-17 17:46

reporter   ~0002269

We have recently started giving SOGo to our customers as they were looking for a web calendar. Frankly speaking, we'd be pretty happy to sponsor any needed feature except for the fact that we are going through a really tight financial situation currently. Anyways, if you could give me a rough estimate as to how much you think would be reasonable amount for sponsorship for this feature, I think I can take it up with the higher authorities.

Cheers,
Rahul.
amaramrahul

amaramrahul

2011-03-18 16:18

reporter   ~0002277

One quick work-around which I could think of is to run two separate instances of sogo with two different configuration files - one has SOGoTrustProxyAuthentication=YES and the other SOGoTrustProxyAuthentication=NO. But I was wondering if it possible to change the default configuration file (.GNUstepDefaults) for the second instance of SOGo or whether the only way to achieve this is by creating a new user altogether?

2011-03-21 14:31

 

proxy-authentication.patch (484 bytes)    
--- a/Main/SOGo.m	2011-01-27 23:42:30.000000000 +0530
+++ b/Main/SOGo.m	2011-03-21 18:43:43.000000000 +0530
@@ -273,8 +273,10 @@
 - (id) authenticatorInContext: (WOContext *) context
 {
   id authenticator;
+  NSString *remoteUser;
 
-  if (trustProxyAuthentication)
+  remoteUser = [[context request] headerForKey: @"x-webobjects-remote-user"];
+  if (trustProxyAuthentication && remoteUser)
     authenticator = [SOGoProxyAuthenticator sharedSOGoProxyAuthenticator];
   else
     {
proxy-authentication.patch (484 bytes)   
amaramrahul

amaramrahul

2011-03-21 14:41

reporter   ~0002279

I believe I have found a reasonably decent solution to my problem. The attached patch checks if "x-webobjects-remote-user" is set. If this is set and SOGoTrustProxyAuthentication=YES, then only SOGo uses the SOGoProxyAutheticator. This way the Proxy (apache2 in our case) tells SOGo whether it is performing authentication or not.

Kindly note that for proxy authentication to work with this patch, you have to ensure that "x-webobjects-remote-user" is passed properly. The proper settings for this can be found in the Issue#0001113.

Perhaps the developers might consider integrating this patch into the main code. Also it might be a good idea to use an additional header such as "x-webobjects-proxy-auth-enabled" instead of "x-webobjects-remote-user", which when set to "yes" implies proxy is performing authentication on behalf of SOGo.

Cheers,
Rahul.
jtg

jtg

2014-03-06 09:44

reporter   ~0006649

I see this ticket is almost three years old. Is there any particular reason that the patch suggested has not been incorporated into the main code?

Issue History

Date Modified Username Field Change
2011-03-17 06:24 amaramrahul New Issue
2011-03-17 16:48 wsourdeau Note Added: 0002268
2011-03-17 16:50 wsourdeau Relationship added related to 0001113
2011-03-17 17:46 amaramrahul Note Added: 0002269
2011-03-18 16:18 amaramrahul Note Added: 0002277
2011-03-21 14:31 amaramrahul File Added: proxy-authentication.patch
2011-03-21 14:41 amaramrahul Note Added: 0002279
2014-03-06 09:44 jtg Note Added: 0006649