Skip to Content.
Sympa Menu

en - Re: [en@sympa] New Sympa build is unable to process Shibboleth SSO session from OKTA

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Mickey Bowling <address@concealed>
  • To: IKEDA Soji <address@concealed>
  • Cc: "address@concealed" <address@concealed>
  • Subject: Re: [en@sympa] New Sympa build is unable to process Shibboleth SSO session from OKTA
  • Date: Wed, 14 Aug 2024 14:01:38 -0700

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?

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




Archive powered by MHonArc 2.6.19+.

Top of Page