Shibboleth SP saml assertion signature validation failure (Cantor, Scott)

Mon Feb 6 21:58:36 UTC 2023

Hi Scott,

We had turned on the logging as "DEBUG" level but it did not give us
enough information. We also tried on a working sp metadata by just
replacing this certificate which caused the error; and we also got the
"Message was signed, but signature could not be verified" error. Do
you have any suggestions on how to troubleshoot or fix this?

-Terry

On Fri, Feb 3, 2023 at 4:00 AM <users-request at shibboleth.net> wrote:

> CAUTION: This email originated from an external sender. Always use caution
> when opening links or attachments from external parties.
> Send users mailing list submissions to
> users at shibboleth.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://shibboleth.net/mailman/listinfo/users
> <https://shibboleth.net/mailman/listinfo/users>
> or, via email, send a message with subject or body 'help' to
> users-request at shibboleth.net
>
> You can reach the person managing the list at
> users-owner at shibboleth.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
> 1. Documentation on 'e' and 's' in execution=eXsY (Jeff Chapin)
> 2. Re: Shibboleth SP saml assertion signature validation failure
> (Cantor, Scott)
> 3. Re: Documentation on 'e' and 's' in execution=eXsY (Cantor, Scott)
> 4. Re: Documentation on 'e' and 's' in execution=eXsY (Jeff Chapin)
> 5. Re: Documentation on 'e' and 's' in execution=eXsY (Cantor, Scott)
> 6. InCommon: Register now for Shibboleth Training & More
> (Jean Chorazyczewski)
> 7. Re: Documentation on 'e' and 's' in execution=eXsY (Jeff Chapin)
> 8. Re: Documentation on 'e' and 's' in execution=eXsY (Cantor, Scott)
> 9. Re: Documentation on 'e' and 's' in execution=eXsY
> (Morgan, Andrew J)
> 10. Re: Documentation on 'e' and 's' in execution=eXsY (Jeff Chapin)
> 11. Validation failure: Failed to resolve an encryption key
> (Mohamed Lrhazi)
> 12. Re: Documentation on 'e' and 's' in execution=eXsY (Chris Reeves)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 Feb 2023 06:49:48 -0600
> From: Jeff Chapin <jeff.chapin at uni.edu>
> To: Shib Users <users at shibboleth.net>
> Subject: Documentation on 'e' and 's' in execution=eXsY
> Message-ID:
> <CAHApK_UhQJymxvVy3LHigS7fjAxfDg_gG09y2tOcy1366Og5_g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I am looking for documentation on what the 'e' and the 's' in the string
> 'execution=eXsY', found in various IDP URLs mean, and I am having a hard
> time coming up with meaningful search terms.
>
> We have an SP that is occasionally having issues, and users fail to login.
> When this happens, they are given an internal server error from the IDP,
> and I have noticed that the URL typically contains something like
> execution=e78s1, which seems relatively high, considering the values I see
> in the logs are usually in the low single digits.....
>
> Thanks,
> Jeff
>
> --
>
> Jeff Chapin,
>
> Panther eSports Adviser
> Systems/Applications Administrator
> ITS-IS, University of Northern Iowa
> Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/7f4d3bac/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/7f4d3bac/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 2 Feb 2023 13:19:33 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: "users at shibboleth.net" <users at shibboleth.net>
> Subject: Re: Shibboleth SP saml assertion signature validation failure
> Message-ID: <5F0C3F9B-D32D-439D-9E04-78F125F586CD at osu.edu>
> Content-Type: text/plain; charset="utf-8"
>
> > We noticed that our customer's public cert has a size of 2237, all our
> > other adfs customer's cert size is less than 2k, we suspected that might
> > be an issue.
>
> If it were, the log would say so. Otherwise the error is exactly what it
> says it is, the metadata's wrong. No amount of claims that "we checked it"
> is relevant to that question.
>
> -- Scott
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 2 Feb 2023 13:55:54 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID: <BF197E7D-2B78-4503-AF0D-D2628F552021 at osu.edu>
> Content-Type: text/plain; charset="utf-8"
>
> > I am looking for documentation on what the 'e' and the 's' in the string
> > 'execution=eXsY', found in various IDP URLs mean,
>
> They aren't somethiing to document, it's an internal detail of Spring
> WebFlow.
> The entire parameter name and value are opaque, in an official sense, but
> there's probably some kind of description of them in the SWF documentation.
> What they are in the implementation is an execution/conversation number and
> a state number.
>
> > I have noticed that the URL typically contains something like
> execution=e78s1,
> > which seems relatively high, considering the values I see in the logs
> are usually
> > in the low single digits.....
>
> That's an SSO loop. Most loops these days are caused by the abomination of
> AJAX combined with a failure to deal with timeouts.
>
> -- Scott
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 2 Feb 2023 08:08:33 -0600
> From: Jeff Chapin <jeff.chapin at uni.edu>
> To: "Cantor, Scott" <cantor.2 at osu.edu>
> Cc: Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID:
> <CAHApK_W1ttApjNUFODURnHf_LVfb2S9U0AStc0049uUdU58jRA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks, I was guessing it was a loop -- and I think I even found what
> causes it to end -- each time through the loop, they appear to be appending
> more header information, until apache, which we are using as a reverse
> proxy, finally chokes on it. Incidentally, it seems like cache/timeouts are
> a factor in this. Thank you for validating my thoughts -- this gives me
> enough to point fingers at the vendor and not let them point them back.
>
> Jeff
>
> On Thu, Feb 2, 2023 at 7:55 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> > > I am looking for documentation on what the 'e' and the 's' in the
> string
> > > 'execution=eXsY', found in various IDP URLs mean,
> >
> > They aren't somethiing to document, it's an internal detail of Spring
> > WebFlow.
> > The entire parameter name and value are opaque, in an official sense, but
> > there's probably some kind of description of them in the SWF
> documentation.
> > What they are in the implementation is an execution/conversation number
> and
> > a state number.
> >
> > > I have noticed that the URL typically contains something like
> > execution=e78s1,
> > > which seems relatively high, considering the values I see in the logs
> > are usually
> > > in the low single digits.....
> >
> > That's an SSO loop. Most loops these days are caused by the abomination
> of
> > AJAX combined with a failure to deal with timeouts.
> >
> > -- Scott
> >
> >
> >
>
> --
>
> Jeff Chapin,
>
> Panther eSports Adviser
> Systems/Applications Administrator
> ITS-IS, University of Northern Iowa
> Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/6c37dddb/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/6c37dddb/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 2 Feb 2023 14:19:39 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: Jeff Chapin <jeff.chapin at uni.edu>
> Cc: Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID: <EE8B9C2F-25B9-4B9E-8E2C-D882D7A9508B at osu.edu>
> Content-Type: text/plain; charset="utf-8"
>
> > Thanks, I was guessing it was a loop -- and I think I even found what
> causes it to
> > end -- each time through the loop, they appear to be appending more
> header
> > information, until apache, which we are using as a reverse proxy,
> finally chokes
> > on it.
>
> If you mean the IdP is proxied, it doesn't accumulate anything like that
> between itself and the client. Loops generally won't break unless they
> break on the SP side or something is done on the IdP to do it (like the
> feature I added to detect them).
>
> -- Scott
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 2 Feb 2023 14:22:30 +0000
> From: Jean Chorazyczewski <jeanc at internet2.edu>
> To: "users at shibboleth.net" <users at shibboleth.net>
> Subject: InCommon: Register now for Shibboleth Training & More
> Message-ID:
> <
> BN8PR08MB619629EF5404E464FA721024EAD69 at BN8PR08MB6196.namprd08.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Hello all,
>
> Does your team have a staff member who needs a crash course on Shibboleth<
> https://incommon.org/academy/shibboleth/
> <https://incommon.org/academy/shibboleth>>?
> Today is a good day to register for InCommon?s Shibboleth training workshop
> ? seats are still available!
>
>
> Shibboleth Workshop
> Sessions (via Zoom): February 13-17, 2023 (partial days)
> Details and registration can be found on our Shibboleth Workshop<
> https://incommon.org/academy/shibboleth/
> <https://incommon.org/academy/shibboleth/>>
> site.
>
> What is the Shibboleth Workshop? Shibboleth provides single sign-on (SSO)
> to services hosted locally or globally using the InCommon Federation.
> You?ll learn how to install, configure, and customize the IdP and SP to
> meet the needs of your organization for single sign-on (SSO) that protects
> both the privacy of your users and your content and services. The virtual
> workshop is delivered through self-paced learning, access to a class Slack
> channel, and office hour sessions with instructors delivered through Zoom.
>
> Learn more and register for Shibboleth training here<
> https://incommon.org/academy/shibboleth/
> <https://incommon.org/academy/shibboleth/>>.
> Registration ends soon!
>
> _ _ _ _ _
>
> More Opportunities for Onboarding and Upskilling
> InCommon Academy is your one-stop connection to the best options for your
> team?s IAM Training in 2023.
>
>
> Registration is open for several upcoming workshops on Grouper<
> https://incommon.org/academy/grouper-school/
> <https://incommon.org/academy/grouper-school>>,
> COmanage<https://incommon.org/academy/comanage/
> <https://incommon.org/academy/comanage>>,
> and midPoint<https://incommon.org/academy/midpoint-evolveum/
> <https://incommon.org/academy/midpoint-evolveum>>.
> Our training lineup offers a blend of virtual workshops spread over the
> course of a week, combined with self-paced work and hands-on activities
> hosted in virtual machines. Participants will build the skills and
> expertise they need.
>
>
> Interested in learning more? View software training highlights for spring
> 2023 at InCommon Academy<https://incommon.org/academy/
> <https://incommon.org/academy>
> >.
>
>
>
> _______
>
> Jean Chorazyczewski | Director, InCommon Academy
> Internet2
>
> Email: jeanc at internet2.edu<mailto:jeanc at internet2.edu>
> Mobile: +1-734-223-2847
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/a9d7a142/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/a9d7a142/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 7
> Date: Thu, 2 Feb 2023 09:01:12 -0600
> From: Jeff Chapin <jeff.chapin at uni.edu>
> To: "Cantor, Scott" <cantor.2 at osu.edu>
> Cc: Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID:
> <CAHApK_XetyfqSx_Z=JOUiiTV=vsf0kU-UFv3EQvvR-x4+N7sSQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Strange. I am getting the following in my apache logs, which sits in front
> of Tomcat:
> AH00971: ajp_marshal_into_msgb: Error appending the header value
> AH00988: ajp_send_header: ajp_marshal_into_msgb failed
>
> The timestamp of this error corresponds to the time users are reporting
> errors -- *AND* the URL of the error is the IDP host, and appears to be a
> HTTPD error -- not shib or Tomcat. My assumption was that *something* --
> the SP, the httpd proxy, the load balancer, or something I can't even think
> of was causing something to append headers. We have seen similar errors in
> the past when one of our SPs was trying to append a *VERY* long header,
> which was longer than the default header length, so I may have jumped to a
> false conclusion.
>
> On Thu, Feb 2, 2023 at 8:19 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> > > Thanks, I was guessing it was a loop -- and I think I even found what
> > causes it to
> > > end -- each time through the loop, they appear to be appending more
> > header
> > > information, until apache, which we are using as a reverse proxy,
> > finally chokes
> > > on it.
> >
> > If you mean the IdP is proxied, it doesn't accumulate anything like that
> > between itself and the client. Loops generally won't break unless they
> > break on the SP side or something is done on the IdP to do it (like the
> > feature I added to detect them).
> >
> > -- Scott
> >
> >
> >
> >
>
> --
>
> Jeff Chapin,
>
> Panther eSports Adviser
> Systems/Applications Administrator
> ITS-IS, University of Northern Iowa
> Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/0f4a412a/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/0f4a412a/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 8
> Date: Thu, 2 Feb 2023 15:27:08 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: Jeff Chapin <jeff.chapin at uni.edu>
> Cc: Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID: <80ED7426-AF82-4875-B5DF-3479FBA5DAD5 at osu.edu>
> Content-Type: text/plain; charset="utf-8"
>
> > We have seen similar errors in the past when one of our SPs was trying to
> > append a *VERY* long header, which was longer than the default header
> length,
> > so I may have jumped to a false conclusion.
>
> My point is the SP might contaminate its own headers with cookies or what
> have you, but it can't make the requests to the IdP "bigger" apart from via
> the request URL or body. It can't "add headers" to the IdP requests.
>
> As for the IdP, I am not aware of any scenario with loops that changes
> much about the size of the requests. Cookies get replaced perhaps, but not
> added.
>
> Even a full login loop in local storage if it happened would replace the
> SP record with the new one, the cache doesn't track > 1 session per SP.
>
> -- Scott
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 2 Feb 2023 18:07:43 +0000
> From: "Morgan, Andrew J" <morgan at oregonstate.edu>
> To: Jeff Chapin <jeff.chapin at uni.edu>, Shib Users
> <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID:
> <
> SJ0P222MB012242C280B73B3271E451A0D1D69 at SJ0P222MB0122.NAMP222.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> I see an AJP error in my Apache logs several times a day as well. Here is
> an example from yesterday:
>
> [Wed Feb 01 17:08:29.923773 2023] [proxy_ajp:error] [pid 31685] AH03229:
> ajp_msg_append_cvt_string(): BufferOverflowException 4 770
> [Wed Feb 01 17:08:29.923979 2023] [proxy_ajp:error] [pid 31685] [client
> 10.214.152.45:62219] AH00971: ajp_marshal_into_msgb: Error appending the
> header value, referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu>
> [Wed Feb 01 17:08:29.924038 2023] [proxy_ajp:error] [pid 31685] [client
> 10.214.152.45:62219] AH00988: ajp_send_header: ajp_marshal_into_msgb
> failed, referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> [Wed Feb 01 17:08:29.924073 2023] [proxy_ajp:error] [pid 31685]
> (120001)APR does not understand this error code: [client
> 10.214.152.45:62219] AH00868: request failed to [::1]:8009 (localhost),
> referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
>
> >From the Apache and IDP logs, this doesn't appear to be a loop. I don't
> know why the header would be too big, either.
>
> We're running this on Debian 10 with their latest apache2 and tomcat9
> packages.
>
> Is this the same error that you are seeing Jeff?
>
> Thanks,
> Andy
>
> ________________________________
> From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott via
> users <users at shibboleth.net>
> Sent: Thursday, February 2, 2023 7:27 AM
> To: Jeff Chapin <jeff.chapin at uni.edu>
> Cc: Cantor, Scott <cantor.2 at osu.edu>; Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
>
> [This email originated from outside of OSU. Use caution with links and
> attachments.]
>
> > We have seen similar errors in the past when one of our SPs was trying to
> > append a *VERY* long header, which was longer than the default header
> length,
> > so I may have jumped to a false conclusion.
>
> My point is the SP might contaminate its own headers with cookies or what
> have you, but it can't make the requests to the IdP "bigger" apart from via
> the request URL or body. It can't "add headers" to the IdP requests.
>
> As for the IdP, I am not aware of any scenario with loops that changes
> much about the size of the requests. Cookies get replaced perhaps, but not
> added.
>
> Even a full login loop in local storage if it happened would replace the
> SP record with the new one, the cache doesn't track > 1 session per SP.
>
> -- Scott
>
>
>
> --
> For Consortium Member technical support, see
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C01%7Cmorgan%40oregonstate.edu%7C9b6e113a54f7486cd60108db0531fbd7%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638109484452455009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ea%2FV7cpPpViBUJiSYIxVp%2B80ZTyxg9R0lEE7%2FZA%2FRqg%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C01%7Cmorgan%40oregonstate.edu%7C9b6e113a54f7486cd60108db0531fbd7%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638109484452455009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ea%2FV7cpPpViBUJiSYIxVp%2B80ZTyxg9R0lEE7%2FZA%2FRqg%3D&reserved=0>
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/e736f28c/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/e736f28c/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 10
> Date: Thu, 2 Feb 2023 12:49:00 -0600
> From: Jeff Chapin <jeff.chapin at uni.edu>
> To: "Morgan, Andrew J" <morgan at oregonstate.edu>
> Cc: Shib Users <users at shibboleth.net>, "Cantor, Scott"
> <cantor.2 at osu.edu>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID:
> <CAHApK_W965vS1MWuk=HDG=yhnSF4LMfy59HVrRcXaLwT25PnWg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> It's very similar -- but we don't seem to have the AH03229:
> ajp_msg_append_cvt_string(): BufferOverflowException portion. It looks like
> we have the rest.
>
> On Thu, Feb 2, 2023 at 12:07 PM Morgan, Andrew J <morgan at oregonstate.edu>
> wrote:
>
> > I see an AJP error in my Apache logs several times a day as well. Here is
> > an example from yesterday:
> >
> > [Wed Feb 01 17:08:29.923773 2023] [proxy_ajp:error] [pid 31685] AH03229:
> > ajp_msg_append_cvt_string(): BufferOverflowException 4 770
> > [Wed Feb 01 17:08:29.923979 2023] [proxy_ajp:error] [pid 31685] [client
> > 10.214.152.45:62219] AH00971: ajp_marshal_into_msgb: Error appending the
> > header value, referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> > [Wed Feb 01 17:08:29.924038 2023] [proxy_ajp:error] [pid 31685] [client
> > 10.214.152.45:62219] AH00988: ajp_send_header: ajp_marshal_into_msgb
> > failed, referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> > [Wed Feb 01 17:08:29.924073 2023] [proxy_ajp:error] [pid 31685]
> > (120001)APR does not understand this error code: [client
> > 10.214.152.45:62219] AH00868: request failed to [::1]:8009 (localhost),
> > referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> >
> > From the Apache and IDP logs, this doesn't appear to be a loop. I don't
> > know why the header would be too big, either.
> >
> > We're running this on Debian 10 with their latest apache2 and tomcat9
> > packages.
> >
> > Is this the same error that you are seeing Jeff?
> >
> > Thanks,
> > Andy
> >
> > ------------------------------
> > *From:* users <users-bounces at shibboleth.net> on behalf of Cantor, Scott
> > via users <users at shibboleth.net>
> > *Sent:* Thursday, February 2, 2023 7:27 AM
> > *To:* Jeff Chapin <jeff.chapin at uni.edu>
> > *Cc:* Cantor, Scott <cantor.2 at osu.edu>; Shib Users <users at shibboleth.net
> >
> > *Subject:* Re: Documentation on 'e' and 's' in execution=eXsY
> >
> > [This email originated from outside of OSU. Use caution with links and
> > attachments.]
> >
> > > We have seen similar errors in the past when one of our SPs was trying
> to
> > > append a *VERY* long header, which was longer than the default header
> > length,
> > > so I may have jumped to a false conclusion.
> >
> > My point is the SP might contaminate its own headers with cookies or what
> > have you, but it can't make the requests to the IdP "bigger" apart from
> via
> > the request URL or body. It can't "add headers" to the IdP requests.
> >
> > As for the IdP, I am not aware of any scenario with loops that changes
> > much about the size of the requests. Cookies get replaced perhaps, but
> not
> > added.
> >
> > Even a full login loop in local storage if it happened would replace the
> > SP record with the new one, the cache doesn't track > 1 session per SP.
> >
> > -- Scott
> >
> >
> >
> > --
> > For Consortium Member technical support, see
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C01%7Cmorgan%40oregonstate.edu%7C9b6e113a54f7486cd60108db0531fbd7%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638109484452455009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ea%2FV7cpPpViBUJiSYIxVp%2B80ZTyxg9R0lEE7%2FZA%2FRqg%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C01%7Cmorgan%40oregonstate.edu%7C9b6e113a54f7486cd60108db0531fbd7%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638109484452455009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ea%2FV7cpPpViBUJiSYIxVp%2B80ZTyxg9R0lEE7%2FZA%2FRqg%3D&reserved=0>
> > To unsubscribe from this list send an email to
> > users-unsubscribe at shibboleth.net
> >
>
>
> --
>
> Jeff Chapin,
>
> Panther eSports Adviser
> Systems/Applications Administrator
> ITS-IS, University of Northern Iowa
> Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/1a0f9040/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/1a0f9040/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 11
> Date: Thu, 2 Feb 2023 14:23:10 -0500
> From: Mohamed Lrhazi <lrhazi at cua.edu>
> To: Shib Users <users at shibboleth.net>
> Subject: Validation failure: Failed to resolve an encryption key
> Message-ID:
> <CAOm-VQ6W2RyV6OqKhBMo-Z3r_ygiL7o5iip9qKm_Sm7JvX2nsw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
> am trying to setup OIDC plugin, and testing using this sample app :
> https://github.com/curityio/example-python-openid-connect-client
> <https://github.com/curityio/example-python-openid-connect-client>
>
> 2023-02-02 13:43:06,648 - 172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6
> <http://172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6>
> -
> > WARN
> >
> [net.shibboleth.idp.plugin.oidc.op.profile.impl.PopulateOIDCEncryptionParameters:258]
> > - Profile Action PopulateOIDCEncryptionParameters: Resolver returned no
> > EncryptionParameters
> > 2023-02-02 13:43:06,647 - 172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6
> <http://172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6>
> -
> > WARN [org.opensaml.xmlsec.impl.BasicEncryptionParametersResolver:243] -
> > Validation failure: Failed to resolve an encryption key
> > 2023-02-02 13:43:06,647 - 172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6
> <http://172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6>
> -
> > DEBUG
> >
> [net.shibboleth.idp.plugin.oidc.op.security.impl.OIDCClientInformationEncryptionParametersResolver:226]
> > - No algorithm information in client information, falling back to default
> > configuration
> > 2023-02-02 13:43:06,647 - 172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6
> <http://172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6>
> -
> > DEBUG
> >
> [net.shibboleth.idp.plugin.oidc.op.profile.impl.PopulateOIDCEncryptionParameters:291]
> > - Profile Action PopulateOIDCEncryptionParameters: Adding OIDC client
> > information to resolution criteria for encryption algorithms
> > 2023-02-02 13:43:06,647 - 172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6
> <http://172.25.0.1/D5F65DA4F127D957EDB2BBFE68C7F0E6>
> -
> > DEBUG
> >
> [net.shibboleth.idp.plugin.oidc.op.profile.impl.PopulateOIDCEncryptionParameters:232]
> > - Profile Action PopulateOIDCEncryptionParameters: Resolving
> > EncryptionParameters for request object decryption
>
>
>
> What could cause this error?
>
> The config for this SP has these settings in it:
>
> <md:SPSSODescriptor protocolSupportEnumeration="
> > http://openid.net/specs/openid-connect-core-1_0.html
> <http://openid.net/specs/openid-connect-core-1_0.html>
> ">
> > <md:Extensions>
> > <oidcmd:OAuthRPExtensions
> > grant_types="authorization_code implicit refresh_token"
> > response_types="id_token code"
> > token_endpoint_auth_method="client_secret_post"
> > scopes="openid profile offline_access" />
> > </md:Extensions>
> > <md:KeyDescriptor>
> > <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#
> <http://www.w3.org/2000/09/xmldsig#>">
> >
> > <oidcmd:ClientSecret>the-shared-secret-here</oidcmd:ClientSecret>
> > </ds:KeyInfo>
> > </md:KeyDescriptor>
> >
> >
> <md:NameIDFormat>urn:mace:shibboleth:metadata:oidc:1.0:nameid-format:public</md:NameIDFormat>
> > <md:AssertionConsumerService
> > Binding="https://tools.ietf.org/html/rfc6749#section-3.1.2
> <https://tools.ietf.org/html/rfc6749#section-3.1.2>
> > "
> > Location="https://localhost:5443/callback"
> > index="1"/>
> > </md:SPSSODescriptor>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://shibboleth.net/pipermail/users/attachments/20230202/e0737798/attachment-0001.htm
> <http://shibboleth.net/pipermail/users/attachments/20230202/e0737798/attachment-0001.htm>
> >
>
> ------------------------------
>
> Message: 12
> Date: Fri, 3 Feb 2023 11:33:57 +0000
> From: Chris Reeves <chris.reeves at york.ac.uk>
> To: Shib Users <users at shibboleth.net>
> Subject: Re: Documentation on 'e' and 's' in execution=eXsY
> Message-ID: <20230203113357.GA1172306 at itsusbeth5.york.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hi both,
>
> The first thing that I would do is check what cookies are being set. Most
> problems that I've seen where headers have been to large have been down to
> cookies. While headers like User-Agent are user-controlled, your average
> user
> isn't going to touch these, but the Cookie header can grow simply by a user
> interacting with a lot of services in the same cookie domain.
>
> As an example, we have a lot of services that are hosted under
> www.york.ac.uk
> <http://www.york.ac.uk>
> ,
> and the various proxy servers set cookies for session affinity. We very
> occasionally come across users who have interacted with too many of these,
> the
> Cookie header grows to large, and then we see these sorts of errors.
>
> Regards,
> Chris
>
> On Thu 02 Feb 2023 at 18:49:00 +0000, Jeff Chapin via users wrote:
> > It's very similar -- but we don't seem to have the AH03229:
> > ajp_msg_append_cvt_string(): BufferOverflowException portion. It looks
> like
> > we have the rest.
> >
> > On Thu, Feb 2, 2023 at 12:07 PM Morgan, Andrew J <morgan at oregonstate.edu
> >
> > wrote:
> >
> > > I see an AJP error in my Apache logs several times a day as well. Here
> is
> > > an example from yesterday:
> > >
> > > [Wed Feb 01 17:08:29.923773 2023] [proxy_ajp:error] [pid 31685]
> AH03229:
> > > ajp_msg_append_cvt_string(): BufferOverflowException 4 770
> > > [Wed Feb 01 17:08:29.923979 2023] [proxy_ajp:error] [pid 31685] [client
> > > 10.214.152.45:62219] AH00971: ajp_marshal_into_msgb: Error appending
> the
> > > header value, referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> > > [Wed Feb 01 17:08:29.924038 2023] [proxy_ajp:error] [pid 31685] [client
> > > 10.214.152.45:62219] AH00988: ajp_send_header: ajp_marshal_into_msgb
> > > failed, referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> > > [Wed Feb 01 17:08:29.924073 2023] [proxy_ajp:error] [pid 31685]
> > > (120001)APR does not understand this error code: [client
> > > 10.214.152.45:62219] AH00868: request failed to [::1]:8009
> (localhost),
> > > referer: https://jobs.oregonstate.edu/
> <https://jobs.oregonstate.edu/>
> > >
> > > From the Apache and IDP logs, this doesn't appear to be a loop. I don't
> > > know why the header would be too big, either.
> > >
> > > We're running this on Debian 10 with their latest apache2 and tomcat9
> > > packages.
> > >
> > > Is this the same error that you are seeing Jeff?
> > >
> > > Thanks,
> > > Andy
> > >
> > > ------------------------------
> > > *From:* users <users-bounces at shibboleth.net> on behalf of Cantor,
> Scott
> > > via users <users at shibboleth.net>
> > > *Sent:* Thursday, February 2, 2023 7:27 AM
> > > *To:* Jeff Chapin <jeff.chapin at uni.edu>
> > > *Cc:* Cantor, Scott <cantor.2 at osu.edu>; Shib Users <
> users at shibboleth.net>
> > > *Subject:* Re: Documentation on 'e' and 's' in execution=eXsY
> > >
> > > [This email originated from outside of OSU. Use caution with links and
> > > attachments.]
> > >
> > > > We have seen similar errors in the past when one of our SPs was
> trying to
> > > > append a *VERY* long header, which was longer than the default header
> > > length,
> > > > so I may have jumped to a false conclusion.
> > >
> > > My point is the SP might contaminate its own headers with cookies or
> what
> > > have you, but it can't make the requests to the IdP "bigger" apart
> from via
> > > the request URL or body. It can't "add headers" to the IdP requests.
> > >
> > > As for the IdP, I am not aware of any scenario with loops that changes
> > > much about the size of the requests. Cookies get replaced perhaps, but
> not
> > > added.
> > >
> > > Even a full login loop in local storage if it happened would replace
> the
> > > SP record with the new one, the cache doesn't track > 1 session per SP.
> > >
> > > -- Scott
> > >
> > >
> > >
> > > --
> > > For Consortium Member technical support, see
> > >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C01%7Cmorgan%40oregonstate.edu%7C9b6e113a54f7486cd60108db0531fbd7%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638109484452455009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ea%2FV7cpPpViBUJiSYIxVp%2B80ZTyxg9R0lEE7%2FZA%2FRqg%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C01%7Cmorgan%40oregonstate.edu%7C9b6e113a54f7486cd60108db0531fbd7%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638109484452455009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ea%2FV7cpPpViBUJiSYIxVp%2B80ZTyxg9R0lEE7%2FZA%2FRqg%3D&reserved=0>
> > > To unsubscribe from this list send an email to
> > > users-unsubscribe at shibboleth.net
> > >
> >
> >
> > --
> >
> > Jeff Chapin,
> >
> > Panther eSports Adviser
> > Systems/Applications Administrator
> > ITS-IS, University of Northern Iowa
> > Phone: 319-273-3162 Email: Jeff.Chapin at uni.edu
>
> > --
> > For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> <https://shibboleth.atlassian.net/wiki/x/ZYEpPw>
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> <https://wiki.shibboleth.net/confluence/x/coFAAg>
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
> ------------------------------
>
> End of users Digest, Vol 140, Issue 3
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230206/85031c19/attachment.htm>