The mailing list for listmasters using Sympa

[IKEDA Soji <address@concealed>]

Hi Mickey,

> 2024/08/15 6:01、Mickey Bowling <address@concealed>のメール:
> 
> Hi Soji,
> 
> > Authentication seems successful, but why Shibboleth SP redirects back to 
> > <https://list.company.com/>?  (I couldn’t figure out what settings caused 
> > this behavior.)
> 
> > It should, at last authentication succeeded, return via redirect to the 
> > original location 
> > <https://list.company.com/sympa/sso_login/shibokta/init>.
> 
> In the /etc/sympa/auth.conf file, under generic_sso we are referencing 
> http_header_prefix and email_http_header with a value of mail.   How are 
> these environment variables utilized and accessed?   I have tried entering 
> random information in place of the value "mail" with the same results.  
> Which logs would be the best to identify how these variables are being used 
> if at all?

First, WWSympa's generic_sso mechanism works as follows.

1.  The user clicks [SSO login] button. A POST request is sent to WWSympa.
2.  WWSympa redirects to 
<https://list.company.com/sympa/sso_login/shibokta/init>.
3.  The area under </sympa/sso_login/shibokta> is protected by shibboleth SP.
    So, if single sign-on has not been established yet, SP redirects to the 
authentication service of IdP. 
4.  The user authenticates themselves using authentication service of IdP.
5.  If the authentication succeeds, SP receives user attributes from IdP and 
returns via redirect to the original location in 2.
6.  WWSympa receives the attributes from SP via CGI environment variable and 
cache the authentication.
7.  The user accesss as an authenticated user as long as the session cookie 
is valid.

Answer to your question: In 6., in most cases, the environment variable 
should only need to be set by email_http_header parameter.
Incidentally, the name of this parameter is misleading; it is the name of the 
environment variable, not the HTTP header.

From the configuration and logs you provided, returning via redirect in 5. is 
not to the location of WWSympa's authentication cache functionality (same 
location as in 2.).
So it is possible that some extra configuration has been added to Apache or 
Shibboleth SP, otherwise maybe something needs to be configured in IdP or SP..


Regards,
— Soji

> Thanks
> 
> On Tue, Aug 13, 2024 at 6:12 PM IKEDA Soji <address@concealed> wrote:
> Hi Mickey,
> 
> > 2024/08/14 7:37、Mickey Bowling <address@concealed>のメール:
> > 
> > Hi Soji,
> > 
> > Thanks for taking a look at this.  The config files are below and the 
> > logs have been attached.
> <<snip>>
> 
> sympa.log:
> 
> > Aug 13 21:45:45 ip-10-224-0-172 wwsympa[5316]: info 
> > main::do_sso_login(shibokta) [robot list.company.com] [session 
> > 60110847240800] [client [client ip]]
> > Aug 13 21:45:45 ip-10-224-0-172 wwsympa[5316]: info main::do_sso_login() 
> > [robot list.company.com] [session 60110847240800] [client [client ip]] 
> > POST request processing
> > Aug 13 21:45:45 ip-10-224-0-172 wwsympa[5316]: info main::do_sso_login() 
> > [robot list.company.com] [session 60110847240800] [client [client ip]] 
> > Redirect user to https://list.company.com/sympa/sso_login/shibokta/init
> 
> Clicking login button caused redirection to the location protected by 
> Shibboleth SP.
> 
> shibd.log:
> 
> > 2024-08-13 21:45:45 DEBUG Shibboleth.Listener [2]: dispatching message 
> > (app-sympa::getHeaders::Application)
> 
> (At this time user might authenticate on IdP.)
> 
> > 2024-08-13 21:46:05 DEBUG Shibboleth.Listener [3] [default]: dispatching 
> > message (default/SAML2/POST)
> > …
> > …
> > 2024-08-13 21:46:05 DEBUG Shibboleth.AttributeDecoder.String [3] 
> > [default]: decoding SimpleAttribute (mail) from SAML 2 Attribute 
> > (emailAddress) with 1 value(s)
> > …
> > 2024-08-13 21:46:05 DEBUG Shibboleth.AttributeFilter [3] [default]: 
> > applying filtering rule(s) for attribute (mail) from 
> > (http://www.okta.com/xxxxxxxxxxxxxxxxxxxx)
> > …
> > 2024-08-13 21:46:05 DEBUG XMLTooling.StorageService [3] [default]: 
> > inserted record (address@concealed) in context (NameID) with expiration 
> > (1723614365)
> 
> A mail attribute seems inserted into the assertion correctly.
> 
> > 2024-08-13 21:46:05 DEBUG Shibboleth.SSO.SAML2 [3] [default]: ACS 
> > returning via redirect to: https://list.company.com/
> > 2024-08-13 21:46:11 INFO Shibboleth.Listener [2]: detected socket 
> > closure, shutting down worker thread
> 
> Authentication seems successful, but why Shibboleth SP redirects back to 
> <https://list.company.com/>?  (I couldn’t figure out what settings caused 
> this behavior.)
> 
> It should, at last authentication succeeded, return via redirect to the 
> original location <https://list.company.com/sympa/sso_login/shibokta/init>.
> 
> 
> Regards,
> 
> — Soji
>