users Digest, Vol 121, Issue 8
Rathore, Rajendra
rarathore at ptc.com
Mon Jul 12 05:23:39 UTC 2021
Hi Scott/Team,
I just saw your mail and you are saying that you applied some patch on installed one, can you please share the details, what is path to fix that issue OOTB since it won't cause issue in old version.
Thanks and Regards,
Rajendra Rathore
9922701491
-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of users-request at shibboleth.net
Sent: Friday, July 9, 2021 5:30 PM
To: users at shibboleth.net
Subject: users Digest, Vol 121, Issue 8
External email from: users-bounces at shibboleth.net
Send users mailing list submissions to
users at shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.net%2Fmailman%2Flistinfo%2Fusers&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996710342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wQndlm7Qi93tyq9pjdXFXHmfb5W3Hawg5Tj%2B2E3C6WE%3D&reserved=0
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. facing apache httpd server start issue with latest shibboleth
version(3.2.2) (Rathore, Rajendra)
2. Re: facing apache httpd server start issue with latest
shibboleth version(3.2.2) (Cantor, Scott)
3. [Solved] Re: ColdFusion and Attribute Access in the SP
(Martin Haase)
4. SAML - confirm MFA auth (Ilya Rumyantsev)
5. DuoOIDC InvalidPathException Illegal char <*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Kazmerzak, John F)
6. Re: DuoOIDC InvalidPathException Illegal char <*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Cantor, Scott)
7. Re: DuoOIDC InvalidPathException Illegal char <*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Rod Widdowson)
8. Re: Shibboleth SP for multiple domains (vadud3 at gmail.com)
9. RE: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information (Nate Klingenstein)
10. Re: [Solved] Re: ColdFusion and Attribute Access in the SP
(Peter Schober)
11. Re: Shibboleth SP for multiple domains (Cantor, Scott)
12. Re: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information (Cantor, Scott)
13. Re: SAML - confirm MFA auth (Cantor, Scott)
14. RE: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information (Nate Klingenstein)
15. RE: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Kazmerzak, John F)
16. Re: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Cantor, Scott)
17. RE: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Kazmerzak, John F)
18. Re: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
(Cantor, Scott)
19. RE: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information (Nate Klingenstein)
20. Shibboleth IDP version 4.1.2 not honoring
wantAuthnRequestsSigned Flag (Kumar, Prasanth (ELS-LON))
21. Re: Shibboleth IDP version 4.1.2 not honoring
wantAuthnRequestsSigned Flag (Peter Schober)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Jul 2021 13:32:50 +0000
From: "Rathore, Rajendra" <rarathore at ptc.com>
To: "users at shibboleth.net" <users at shibboleth.net>
Subject: facing apache httpd server start issue with latest shibboleth
version(3.2.2)
Message-ID:
<SJ0PR17MB46140971A3E68FF584E92049B6199 at SJ0PR17MB4614.namprd17.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi Team,
I am facing below issue with latest shibboleth Version 3.2.2, it working fine with old version 3.1.x version.
httpd: Syntax error on line 15 of /opt/ptc/lion_32/HTTPServer/conf/conf.d/00-1mod_shib.conf: Cannot load /usr/lib64/shibboleth/mod_shib_24.so into server: /usr/lib64/libldap_r-2.4.so.2: undefined symbol: ber_sockbuf_io_udp
issue seems to be some library conflict with open ldap, can you please suggest why this issue occurred with latest version.
Thanks and Regards,
Rajendra Rathore
9922701491
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.net%2Fpipermail%2Fusers%2Fattachments%2F20210708%2Fa2bbe2e8%2Fattachment-0001.htm&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996710342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pUy56i%2B7nZ%2BqrwH4SCryLCLsXMwGLFarPCZXrV2eiNI%3D&reserved=0>
------------------------------
Message: 2
Date: Thu, 8 Jul 2021 13:44:24 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: facing apache httpd server start issue with latest
shibboleth version(3.2.2)
Message-ID: <A15E68CB-DDBE-47FD-8813-2BD11925C80A at osu.edu>
Content-Type: text/plain; charset="utf-8"
The builds are done the same as always, against unmodified distribution packages only. If there's an issue, then either there's a conflict with Red Hat's own code (unlikely), or you're doing things that are absolutely out of bounds such as using your own Apache build or using RPMs on a platform other than the exact one they're built on.
I just patched an install on CentOS 8 and it loaded fine. I have no reason to think anything would be different anywhere else.
-- Scott
------------------------------
Message: 3
Date: Thu, 8 Jul 2021 16:52:27 +0200
From: Martin Haase <martin.haase at daasi.de>
To: Shib Users <users at shibboleth.net>
Subject: [Solved] Re: ColdFusion and Attribute Access in the SP
Message-ID: <42627814-4e08-c1db-921c-8836f33602df at daasi.de>
Content-Type: text/plain; charset="utf-8"
Hi List,
thanks to a hint by Scott via the Consortium's member chat, this could
be resolved: Error 403 is a hint that a newer Tomcat would not accept
the attributes injected by the SP. To make Tomcat accept the SP's
attributes, the property *allowedRequestAttributesPattern* in Tomcat's
configuration must be set to a regular expression matching the expected
attribute names. See
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fajp.html&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996710342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F7kuf%2FcZIy4ZID9OTz8FAOJXtCG5MZAt2Q7K%2F14VFlw%3D&reserved=0
Hope this helps others,
Martin
Am 07.07.21 um 14:02 schrieb Martin Haase:
> Dear List,
>
> maybe someone in here has already done this. We have installed a current
> SP on Linux with Apache2.4 that proxies via AJP to a Tomcat that runs a
> ColdFusion Application. We have issues with seeing attributes at the
> application. A variable like "CGI.EPPN", "CGI.HTTP_EPPN" etc. would not
> be available for dump although "eppn" is visible in the session, and
> "AJP_eppn" in phpinfo() as well.
>
> We tried both passive and active protection of <Location />, with
> ProxyPass of "/" to ajp://localhost (excluding the Shib Handler URL).
>
> Do you have any idea?
>
> Cheers
>
> Martin
>
> P.S: Maybe this has something to do with it: The application seems to
> require a "Require all granted" in its <Location>. However, when I want
> to use passive protection and say "Require shibboleth", then these two
> directives seem to disturb each other. As soon as I comment the "Require
> all granted", the application would answer with a HTTP 403.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.net%2Fpipermail%2Fusers%2Fattachments%2F20210708%2F35d7b673%2Fattachment-0001.htm&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996710342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AuMMst1YrEzWBEGlUMaJa6P%2F5c77MkaSnn4dSzM7sho%3D&reserved=0>
------------------------------
Message: 4
Date: Thu, 8 Jul 2021 20:08:24 +0200
From: Ilya Rumyantsev <iliggio at gmx.de>
To: users at shibboleth.net
Subject: SAML - confirm MFA auth
Message-ID:
<trinity-d5e313a6-c97d-4980-ab23-5b254bbe73d4-1625767704287 at 3c-app-gmx-bap04>
Content-Type: text/plain; charset=UTF-8
Hi All,
we have a shibboleth IDP configured to authenticate users by smartcard (certificate based auth). This is technically a 2 Factor authentication.
How would we configure shibboleth IDP in a way that it confirms to the SPs (in the assertion) that a 2-Factor auth has taken place?
Thanks a lot
------------------------------
Message: 5
Date: Thu, 8 Jul 2021 18:31:53 +0000
From: "Kazmerzak, John F" <john-kazmerzak at uiowa.edu>
To: "users at shibboleth.net" <users at shibboleth.net>
Subject: DuoOIDC InvalidPathException Illegal char <*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID:
<CH2PR04MB67103D2CB14190ECFC7A44B591199 at CH2PR04MB6710.namprd04.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am migrating from idp.authn.Duo to the idp.authn.DuoOIDC module. When the flow transfers from authn/Password to authn/DuoOIDC an exception is thrown.
ERROR {https-jsse-nio-443-exec-15} net.shibboleth.idp.authn:-2 Uncaught runtime exception
org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from URL [jar:war:file:/E:/Shibboleth/war/idp.war*/WEB-INF/lib/idp-plugin-duo-impl-1.1.1.jar!/META-INF/net/shibboleth/idp/flows/authn/DuoOIDC/duo-oidc-authn-beans.xml]; nested exception is java.nio.file.InvalidPathException: Illegal char <*> at index 9: classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:417)
Caused by: java.nio.file.InvalidPathException: Illegal char <*> at index 9: classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
This is the environment I tested on.
IdP: 4.1.2
OS: Windows Server 2016
Java: Amazon Corretto 11.0.11.9.1
Servlet Container: Tomcat 9.0.50
If I edit /WEB-INF/lib/idp-plugin-duo-impl-1.1.1.jar!/META-INF/net/shibboleth/idp/flows/authn/DuoOIDC/duo-oidc-authn-beans.xml to remove the wildcard (*) in the classpath on line 67 [1] then the authn/DuoOIDC executes without error.
Looking at the commit history [2] for idp-duo-impl/src/main/resources/META-INF/net/shibboleth/idp/flows/authn/DuoOIDC/duo-oidc-authn-beans.xml I see the following change.
- <import resource="classpath*:duo-client-factory-bean.xml" />
+ <import resource="classpath*:/net/shibboleth/idp/plugin/authn/duo/duo-client-factory-bean.xml" />
Is the wildcard still necessary? If not, may I submit a Jira issue to have it removed? Does the solution to this issue originate elsewhere?
Kaz
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.shibboleth.net%2Fview%2F%3Fp%3Djava-idp-plugin-duo.git%3Ba%3Dblob%3Bf%3Didp-duo-impl%2Fsrc%2Fmain%2Fresources%2FMETA-INF%2Fnet%2Fshibboleth%2Fidp%2Fflows%2Fauthn%2FDuoOIDC%2Fduo-oidc-authn-beans.xml%3Bhb%3D1ad154e370662647f2549fb0cec6227de070a380%23l67&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YprugmpBNC2XN3A03qvdC2%2F80RjV%2B24o4FYQlUTn7eU%3D&reserved=0
[2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.shibboleth.net%2Fview%2F%3Fp%3Djava-idp-plugin-duo.git%3Ba%3Dcommitdiff%3Bh%3D3bb1aa2e34e10cdf2a98a5722ebc593bac814f81&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qh4%2F0zqrV73WZtnIuITqeagda3afKFXFPmG3Q37Enpg%3D&reserved=0
------------------------------
Message: 6
Date: Thu, 8 Jul 2021 18:44:35 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: DuoOIDC InvalidPathException Illegal char <*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID: <76A66D21-750E-4741-B71D-D9F19B6B6839 at osu.edu>
Content-Type: text/plain; charset="utf-8"
This is Windows being Windows, and no, it's not going to get reverted, it's a necessary behavior.
We use the same syntax all over the place so I doubt it's as simple as just that one issue. It shouldn't even start up without the plugin. So something else is probably going on, possibly just as simple as using the drive letter that way.
I don't know whether it's possible to get it to work on Windows or not, but your best option is to never use a non-default location for the IdP. Whatever has to be done to ensure that is the best choice most of the time. Use a symlink if you have to.
Either way, please file a bug.
-- Scott
------------------------------
Message: 7
Date: Thu, 8 Jul 2021 19:55:30 +0100
From: Rod Widdowson <rdw at steadingsoftware.com>
To: Shib Users <users at shibboleth.net>
Subject: Re: DuoOIDC InvalidPathException Illegal char <*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID:
<52D6B7C1-C9A2-4B16-9F1D-26F6A5351480 at steadingsoftware.com>
Content-Type: text/plain; charset=utf-8
I?m away from my desk but I have a vague memory of bottoming this out last year?
Maybe check for back slashes in all your paths and replace them with unix style forward slashes?
------------------------------
Message: 8
Date: Thu, 8 Jul 2021 14:55:28 -0400
From: vadud3 at gmail.com
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth SP for multiple domains
Message-ID:
<CAOHBbgXuiEZyi5WrX7pK1Swi63md7WNNWK-TuWZOhfaTvgSVKA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello All,
I am still looking for some suggestions on this.
Thanks,
Asif
On Wed, Jul 7, 2021 at 2:07 PM <vadud3 at gmail.com> wrote:
>
> On Wed, Jul 7, 2021 at 5:37 AM Peter Schober <peter.schober at univie.ac.at>
> wrote:
> >
> > * vadud3 at gmail.com <vadud3 at gmail.com> [2021-07-06 23:19]:
> > > We?ve tried following the following two links / options, but couldn?t
> > > get it working:
> > >
> > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.cac.washington.edu%2Fpages%2Fviewpage.action%3FpageId%3D61703128&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ytCF2MiWhVY13kiKnw%2Fk5ytgEwk7vk9%2BytFEL3DUiZg%3D&reserved=0
> > >
> > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.cac.washington.edu%2Fpages%2Fviewpage.action%3FpageId%3D28939166&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eNYjNgfGDel8uxLB4MdPgASlAfFrzSNo7oDKFbjtZDM%3D&reserved=0
> > [...]
> > > We are looking to see if we are going down the right path. Which
> > > option should we be trying to complete? Should we be trying to do
> > > this under 1 entityID or use separate entityIDs for each site that we
> > > have?
> >
> > 1. Contrary to popular belief "couldn't get it working" is not a
> > technical error description that would enable anyone to help you solve
> > your problem.
> >
> > 2. Those instructions are not from the official software documentation
> > (which doesn't mean they're bad) and expecting people to read 3rd
> > party documentation only to help you fix a problem you haven't even
> > described is asking a bit much, IMO.
> >
> > 3. Only you can know whether one entityID will suffice for your use
> > case or not. Of course you also don't mention anything about the
> > number or kind of services so it's impossible for anyone else to say.
> > Follwing Occam's razor a single one should suffice unless you *know*
> > your use case requires multiple.
> > (If the IDPs need to be able to differentiate those logical SPs in
> > order to apply differing policies then you'll likely need multiple
> > entityIDs for the logical SPs. If you can get away without that avoid
> > it, of course.)
> >
> > -peter
> > --
> > For Consortium Member technical support, see
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wOAQwHD9uwrvo9JADfKwR6SJ3y3u%2FXoUHxptlXrnk%2Fc%3D&reserved=0
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
> I have a cluster of jira application nodes behind a set of proxy servers
> running apache 2.4. These proxy servers
> are also setup as SP providers
>
> Here is the current relevant config (sanitized)
>
> node1-vhost.conf
> =============
> <Location /jira>
> <If "%{REQUEST_URI} =~ m#^/(jira/server-info|jira/s/).*#">
> Satisfy Any
> </If>
> <If "%{REQUEST_URI} =~ m#^/jira/rest/collectors/.*#">
> RequestHeader set X-Atlassian-Token nocheck
> </If>
> Order allow,deny
> Allow from all
> AuthType Shibboleth
> Header set X-Forwarded-Proto "https"
> ShibUseHeaders On
> ShibRequestSetting requireSession true
> *ShibRequestSetting applicationId node1*
> <RequireAny>
> Require shib-attr AuthType "standard, x509, securePlus2,
> securePlus3, piv"
> Require shib-attr AppAuth true
> Require shib-attr idp
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsts.example.net%2F76c-94d-4a2-bb7a-2354a%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QJN5kmjIMMIChXW792YM8iL1ql1T6LQlkupxUIb6PBg%3D&reserved=0
> </RequireAny>
> </Location>
>
> discovery file shibboleth-ds.conf
> =========================
> <IfModule mod_alias.c>
> <Location /shibboleth-ds>
> Allow from all
> <IfModule mod_shib.c>
> AuthType shibboleth
> ShibRequestSetting requireSession false
> require shibboleth
> </IfModule>
> </Location>
> Alias /shibboleth-ds/idpselect_config.js
> /etc/shibboleth-ds/idpselect_config.js
> Alias /shibboleth-ds/idpselect.js /etc/shibboleth-ds/idpselect.js
> Alias /shibboleth-ds/idpselect.css /etc/shibboleth-ds/idpselect.css
> Alias /shibboleth-ds/index.html /etc/shibboleth-ds/index.html
> Alias /shibboleth-ds/blank.gif /etc/shibboleth-ds/blank.gif
> </IfModule>
>
> shibboleth2.xml (note: server.example.org is cluster front end)
> ===============================================
> <ApplicationDefaults id="default" entityID="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FDCjfus4e89SW4F8gAPHUS9KFXN2EfaBYlfWwV6io4%3D&reserved=0
> "
> REMOTE_USER="nameid eppn uid persistent-id targeted-id"
> signing="true" encryption="true">
>
> <Sessions lifetime="28800" timeout="1800" relayState="ss:mem"
> checkAddress="false" consistentAddress="false"
> handlerSSL="true" cookieProps="https">
> <SSO discoveryProtocol="SAMLDS" discoveryURL="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.org%2Fshibboleth-ds%2Findex.html&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rCv%2Fgv%2FnNKGYA%2FhUeML8RGvf3ynVRKw9nbVT4aCXXE0%3D&reserved=0">
> SAML2 SAML1
> </SSO>
> <Logout>SAML2 Local</Logout>
> <Handler type="MetadataGenerator" Location="/Metadata"
> signing="false"/>
> ......
> </Sessions>
> <*ApplicationOverride id="node1"
> entityID="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnode1.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qNP0RarGEJ5K4ML7lfUfbhbONkFukjsctikSqi3PXSo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnode1.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qNP0RarGEJ5K4ML7lfUfbhbONkFukjsctikSqi3PXSo%3D&reserved=0>"*/>
> <ApplicationOverride id="node2" entityID="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnode2.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EA573vim5dWnK3wTsW%2B4KSrH1C%2FoEnAyyXMWz%2BqjZ9Q%3D&reserved=0"/>
> <ApplicationOverride id="node3" entityID="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnode3.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6mIiTppAp4%2BrHDeTnQCisazfwCgNTHVZcZnuTrjQx0Y%3D&reserved=0"/>
> </ApplicationDefaults>
>
> I can get to https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.org%2Fjira&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oNBg1p5Sz8dUS1u1uOGvheBbehfMUenpL%2BTvvuj3qZU%3D&reserved=0 and authentication works
> fine.
> saml request for server
>
> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> AssertionConsumerServiceURL="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.org%2FShibboleth.sso%2FSAML2%2FPOST&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SKI9JWt%2FYvpTZxa%2BPjszXTRG1x4czNgxrTK7oJSr9Jc%3D&reserved=0" Destination="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fssotest.example.org%2Fadfs%2Fls%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HRnrqliGJ6hzqideprXitBkEP0JFRO5iP9usL40%2BuqI%3D&reserved=0"
> ID="_8b4283a72909133856ada1a3c3e61118" IssueInstant="2021-07-07T17:25:34Z"
> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Version="2.0">
> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r%2FDCjfus4e89SW4F8gAPHUS9KFXN2EfaBYlfWwV6io4%3D&reserved=0</saml:Issuer>
> <samlp:NameIDPolicy AllowCreate="1"/>
> </samlp:AuthnRequest>
>
> But I am failing when I try to connect to https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnode1.example.org%2Fjira&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996720304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rwQ%2FjE7OJ%2FHSG3t5K4MEO1%2BQqHvcvQYDFzgJX725gZ8%3D&reserved=0.
> It gives me an (I think from IdP) error saying an error orrcured and
> provides some parameters in error
> details like Activity ID, Relying party, User agent string, etc.
>
> saml request for node1
>
> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> AssertionConsumerServiceURL="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnode1.example.org%2FShibboleth.sso%2FSAML2%2FPOST&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C5ajRoz88MTz9rfhoQsq93ns1UX2kVENEStEdXE2JO0%3D&reserved=0" Destination="
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fssotest.example.org%2Fadfs%2Fls%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=97E%2BjBG6Gim7brKzC0pG%2BC5l88Q4VFCH%2FVm2U7NPC8E%3D&reserved=0"
> ID="_a672076156126c72dfe845759e79a7e7" IssueInstant="2021-07-07T17:10:41Z"
> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Version="2.0">
> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.org%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5nkMn2D2v1DE4BU5%2FNDzc2I4Yr7VanRrvwzk9lIhjTk%3D&reserved=0</saml:Issuer>
> <samlp:NameIDPolicy AllowCreate="1"/>
> </samlp:AuthnRequest>
>
> Looking for some help to troubleshoot this.
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.net%2Fpipermail%2Fusers%2Fattachments%2F20210708%2Fd654b82f%2Fattachment-0001.htm&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qvpBjxVAVSRLqv74JMxpPS%2Fk0HAkMXKqDu4mb%2Ft%2FBRI%3D&reserved=0>
------------------------------
Message: 9
Date: Thu, 8 Jul 2021 18:59:27 +0000
From: Nate Klingenstein <ndk at signet.id>
To: Shib Users <users at shibboleth.net>
Subject: RE: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information
Message-ID:
<0101017a877d341b-ec28bfa5-00c5-4f95-af3e-31147efccad2-000000 at us-west-2.amazonses.com>
Content-Type: text/plain; charset=UTF-8
To close the loop on this one(yuk yuk), Scott's right.
We finally contacted users in the midst of loops and actually got browser traces from them, because getting them from IIS would have been painful in this environment.
The module is attempting to set the cookie before redirecting the user. After hitting:
url "https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshib.redacted%2FShibboleth.sso%2FSAML2%2FPOST&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t0fOym37NnUU6xd0ZLPOdDWZecTJG3KAqAKh%2FK1VGNw%3D&reserved=0"
with a valid SAML response:
"<samlp:Response ID=\"_4f?ertion></samlp:Response>"
That gets processed successfully and a shibsession Set-Cookie is sent back:
name "Set-Cookie"
value "_shibsession_64656661756?x.com; path=/; HttpOnly"
But the cookie never appears to be sent in the request back to the module until the successful login and termination of the loop.
Shibboleth gets flooded with novel sessions during this time.
Now, on to figure out why the cookie is not being returned, and thank you to Scott for suggesting this. I'm baffled but en route to enlightenment.
--------
Signet, Inc.
The Art of Access ?
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.signet.id%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZZcx2S4A57SgTsC3Z39swQi5C6dKFy4dJlsotDa%2Bq24%3D&reserved=0
-----Original message-----
From: Cantor, Scott
Sent: Wednesday, July 7 2021, 8:16 pm
To: Shib Users
Subject: Re: IIS Module Intermittently Failing to Query Daemon over a TCPListener for Session Information
There's almost certainly no session cookie provided. No cookie + the passive rule means nothing much happens. The session cache will try and find the cookie to locate a key to use to search for a session and if there's no cookie, there's no key and nothing more happens, it just returns no session and goes on with life. It's not "failing" to query the daemon, it just has no reason to since there's nothing to query against.
That's the normal reason for all loops. The only difference is the loop is self-inflicted and not the SP doing it itself.
-- Scott
--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ei4REL04o1kBdC%2BkmPDrEbipAqJmNHReN9WWZdhw51A%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ei4REL04o1kBdC%2BkmPDrEbipAqJmNHReN9WWZdhw51A%3D&reserved=0>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>
------------------------------
Message: 10
Date: Thu, 8 Jul 2021 21:02:55 +0200
From: Peter Schober <peter.schober at univie.ac.at>
To: users at shibboleth.net
Subject: Re: [Solved] Re: ColdFusion and Attribute Access in the SP
Message-ID: <20210708190255.jlxmy33lwigmtahf at aco.net>
Content-Type: text/plain; charset=us-ascii
* Martin Haase <martin.haase at daasi.de> [2021-07-08 16:52]:
> To make Tomcat accept the SP's attributes, the property
> *allowedRequestAttributesPattern* in Tomcat's configuration must be
> set to a regular expression matching the expected attribute
> names.
Yeah, sorry, I was bitten by that too recently but didn't realise you
were having the same problem from your description. (I misread your
'although "eppn" is visible in the session' to mean you're getting
eppn through to Tomcat.)
Tomcat 9.0.31 from Debian Buster rejects all requests carrying
attributes with the rather generic error message:
"The server understood the request but refuses to authorize it."
Only once I swapped in Tomcat 9.0.39 (from Buster Backports) did log
messages like these finally appear:
[warning] Rejecting request due to unknown request attribute [Shib-Handler] received from reverse proxy
[warning] Rejecting request due to unknown request attribute [Shib-Application-ID] received from reverse proxy
[warning] Rejecting request due to unknown request attribute [Shib-Session-ID] received from reverse proxy
[warning] Rejecting request due to unknown request attribute [Shib-Identity-Provider] received from reverse proxy
etc.
Disabling that "feature" by setting the value to ^.*$ was a quick fix
once the missing log messages made clear what's actually happening.
-peter
------------------------------
Message: 11
Date: Thu, 8 Jul 2021 19:06:02 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth SP for multiple domains
Message-ID: <4F7E0DA3-480F-482E-8BDE-7B3EB5D1E16E at osu.edu>
Content-Type: text/plain; charset="utf-8"
On 7/8/21, 2:55 PM, "users on behalf of vadud3 at gmail.com" <users-bounces at shibboleth.net on behalf of vadud3 at gmail.com> wrote:
> I am still looking for some suggestions on this.
The SP runs on any domains you host it on out of the box, provided you add the necessary endpoints to the metadata so that the requested response locations are accepted by the IdP. Any problems you have are likely due to invalid metadata given to the IdP missing the necessary endpoints.
-- Scott
------------------------------
Message: 12
Date: Thu, 8 Jul 2021 19:08:40 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information
Message-ID: <B5EFBCAC-CA1F-4D7A-A86D-20CBE9F44C46 at osu.edu>
Content-Type: text/plain; charset="utf-8"
On 7/8/21, 2:59 PM, "users on behalf of Nate Klingenstein" <users-bounces at shibboleth.net on behalf of ndk at signet.id> wrote:
> Now, on to figure out why the cookie is not being returned
Generally cookie size limits of some kind.
-- Scott
------------------------------
Message: 13
Date: Thu, 8 Jul 2021 19:09:58 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: SAML - confirm MFA auth
Message-ID: <312B2822-EAF5-4367-AE7B-B56FF4E5309F at osu.edu>
Content-Type: text/plain; charset="utf-8"
On 7/8/21, 2:08 PM, "users on behalf of Ilya Rumyantsev" <users-bounces at shibboleth.net on behalf of iliggio at gmx.de> wrote:
> How would we configure shibboleth IDP in a way that it confirms to the SPs (in the assertion) that a 2-Factor
> auth has taken place?
The supportedPrincipals property associated with login flows determines what AuthnContextClassRef values are associated with requests and responses, the documentation covers it at length.
The specifics vary by version now because of the changes in 4.1 to simplify configuration.
-- Scott
------------------------------
Message: 14
Date: Thu, 8 Jul 2021 19:18:59 +0000
From: Nate Klingenstein <ndk at signet.id>
To: Shib Users <users at shibboleth.net>
Subject: RE: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information
Message-ID:
<0101017a878f1774-02d5602b-c07b-4435-967c-14e35e1ac63b-000000 at us-west-2.amazonses.com>
Content-Type: text/plain; charset=UTF-8
> Generally cookie size limits of some kind.
So, we've seen this with Edge(ium) and Chrome, and during login with an Azure IdP, the same client is able to toss around at least 2,506 bytes' worth of cookies. But, I think you're on the right track. The request to the login page is passing through an F5 reverse proxy and IIS, either of which might be throttling this, and there are cookies set by the application too. We'll go digging further.
Thanks again.
--------
Signet, Inc.
The Art of Access ?
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.signet.id%2F&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZZcx2S4A57SgTsC3Z39swQi5C6dKFy4dJlsotDa%2Bq24%3D&reserved=0
------------------------------
Message: 15
Date: Thu, 8 Jul 2021 19:21:41 +0000
From: "Kazmerzak, John F" <john-kazmerzak at uiowa.edu>
To: Shib Users <users at shibboleth.net>
Subject: RE: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID:
<CH2PR04MB67100AB394433326EC17419D91199 at CH2PR04MB6710.namprd04.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Scott and Rod, those were both very helpful comments. I appreciate it. The files conf\authn\duo-oidc-authn-config.xml, and conf\authn\duo-oidc.properties had LF line endings. Converting those to CRLF corrected the issue.
Kaz
-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Thursday, July 8, 2021 13:45
To: Shib Users <users at shibboleth.net>
Subject: [External] Re: DuoOIDC InvalidPathException Illegal char <*> at index 9: classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
This is Windows being Windows, and no, it's not going to get reverted, it's a necessary behavior.
We use the same syntax all over the place so I doubt it's as simple as just that one issue. It shouldn't even start up without the plugin. So something else is probably going on, possibly just as simple as using the drive letter that way.
I don't know whether it's possible to get it to work on Windows or not, but your best option is to never use a non-default location for the IdP. Whatever has to be done to ensure that is the best choice most of the time. Use a symlink if you have to.
Either way, please file a bug.
-- Scott
--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ei4REL04o1kBdC%2BkmPDrEbipAqJmNHReN9WWZdhw51A%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
Message: 16
Date: Thu, 8 Jul 2021 19:30:22 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID: <16BCD9D6-4003-4889-A456-56219B129D64 at osu.edu>
Content-Type: text/plain; charset="utf-8"
On 7/8/21, 3:21 PM, "users on behalf of Kazmerzak, John F" <users-bounces at shibboleth.net on behalf of john-kazmerzak at uiowa.edu> wrote:
> Scott and Rod, those were both very helpful comments. I appreciate it. The files conf\authn\duo-oidc-authn
>-config.xml, and conf\authn\duo-oidc.properties had LF line endings. Converting those to CRLF corrected the
> issue.
That's....very weird. Please file a bug either way, we have no idea why that would matter.
We can't easily worry about linefeeds anymore, that's just impossible to accommodate with the way the plugins are being done now. If it comes to it, then Windows support will have to go away, but we have to know what we're dealing with. We might have to just inject some kind of filtering step in the resource loader.
-- Scott
------------------------------
Message: 17
Date: Thu, 8 Jul 2021 20:02:06 +0000
From: "Kazmerzak, John F" <john-kazmerzak at uiowa.edu>
To: Shib Users <users at shibboleth.net>
Subject: RE: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID:
<CH2PR04MB671040C7017C89E25999CFCB91199 at CH2PR04MB6710.namprd04.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
The line ending change did not fix the issue. I performed the test incorrectly. A bug has been filed.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.shibboleth.net%2Fjira%2Fbrowse%2FJDUO-49&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8nb9hRMaykKB4f38hH9bGBv9dSnU2AnspRcv9S5OyjM%3D&reserved=0
Kaz
-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Thursday, July 8, 2021 14:30
To: Shib Users <users at shibboleth.net>
Subject: Re: [External] Re: DuoOIDC InvalidPathException Illegal char <*> at index 9: classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
On 7/8/21, 3:21 PM, "users on behalf of Kazmerzak, John F" <users-bounces at shibboleth.net on behalf of john-kazmerzak at uiowa.edu> wrote:
> Scott and Rod, those were both very helpful comments. I appreciate
>it. The files conf\authn\duo-oidc-authn -config.xml, and
>conf\authn\duo-oidc.properties had LF line endings. Converting those to CRLF corrected the issue.
That's....very weird. Please file a bug either way, we have no idea why that would matter.
We can't easily worry about linefeeds anymore, that's just impossible to accommodate with the way the plugins are being done now. If it comes to it, then Windows support will have to go away, but we have to know what we're dealing with. We might have to just inject some kind of filtering step in the resource loader.
-- Scott
--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ei4REL04o1kBdC%2BkmPDrEbipAqJmNHReN9WWZdhw51A%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
Message: 18
Date: Thu, 8 Jul 2021 20:53:35 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: [External] Re: DuoOIDC InvalidPathException Illegal char
<*> at index 9:
classpath*:\net\shibboleth\idp\plugin\authn\duo\duo-client-factory-bean.xml
Message-ID: <A017CE5B-9CE2-4DE4-8B29-B41BB044C0CC at osu.edu>
Content-Type: text/plain; charset="utf-8"
On 7/8/21, 4:02 PM, "users on behalf of Kazmerzak, John F" <users-bounces at shibboleth.net on behalf of john-kazmerzak at uiowa.edu> wrote:
> The line ending change did not fix the issue. I performed the test incorrectly. A bug has been filed.
Thank you, I was pretty confident there was no way that was going to help.
-- Scott
------------------------------
Message: 19
Date: Thu, 8 Jul 2021 22:23:03 +0000
From: Nate Klingenstein <ndk at signet.id>
To: Shib Users <users at shibboleth.net>
Subject: RE: IIS Module Intermittently Failing to Query Daemon over a
TCPListener for Session Information
Message-ID:
<0101017a88379be7-fb6df2e0-099f-499c-8a92-abe4d6c36c57-000000 at us-west-2.amazonses.com>
Content-Type: text/plain; charset=UTF-8
The application in question uses iframes extensively and the browser traces from clients show the OpenSAML cookie being set with SameSite None, but without a secure flag. For the clients that successfully login, the OpenSAML cookie is being set and sent successfully, but it's not in the clients that are failing.
The only cookies that are sent in the request to the login page after SAML processing by the looping clients are all set as SameSite None and Secure.
So, is it plausible that this is a SameSite issue and that the proper fix is that cookieProps needs to be set to "https" and a new sameSiteSession attribute needs to be added with a value of "None" to the session element?
Other than issues with older versions of Safari(and way deprecated browsers), is there any potential adverse impact from changing these settings? I can't think of any.
------------------------------
Message: 20
Date: Fri, 9 Jul 2021 09:06:09 +0000
From: "Kumar, Prasanth (ELS-LON)" <p.kumar.13 at elsevier.com>
To: Shib Users <users at shibboleth.net>
Subject: Shibboleth IDP version 4.1.2 not honoring
wantAuthnRequestsSigned Flag
Message-ID:
<CO1PR08MB67534AC93F1ED60ABB5F38F4B0189 at CO1PR08MB6753.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
When shibboleth service provider sends an non-signed authn requests then identify provider should be rejecting the request in this case.
Please see our configuration changes below
On metadata this flag set to false - <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">
Following https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fdisplay%2FIDP4%2FSAML2SSOConfiguration&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b4hBapIKdQTkrP1UPHBHTcIcuBniYNbWjmeysXEklyw%3D&reserved=0 configuration changes on IDP side doesn't seems to working:
idp.saml.honorWantAuthnRequestsSigned=true in idp.properties file
Do I have to enable the flag in <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" AuthnRequestsSigned="false">
Thanks in advance,
Prasanth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.net%2Fpipermail%2Fusers%2Fattachments%2F20210709%2F897f33e8%2Fattachment-0001.htm&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Vufrqg34J9VdmSbkSR2AeuhYsW8%2FD%2B4z5z2LenqZEE0%3D&reserved=0>
------------------------------
Message: 21
Date: Fri, 9 Jul 2021 12:28:45 +0200
From: Peter Schober <peter.schober at univie.ac.at>
To: users at shibboleth.net
Subject: Re: Shibboleth IDP version 4.1.2 not honoring
wantAuthnRequestsSigned Flag
Message-ID: <20210709102845.jtr4w7i3m56lfwmo at aco.net>
Content-Type: text/plain; charset=us-ascii
* Kumar, Prasanth (ELS-LON) <p.kumar.13 at elsevier.com> [2021-07-09 11:06]:
> When shibboleth service provider sends an non-signed authn requests
> then identify provider should be rejecting the request in this case.
Is there anything worth protecting in the authentication request --
what specifically?
Otherwise don't do that (any of it: don't sign them, don't change
metadata about signed authn requests).
> On metadata this flag set to false - <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">
Which should be the same thing as not specifying it.
> Following https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fdisplay%2FIDP4%2FSAML2SSOConfiguration&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b4hBapIKdQTkrP1UPHBHTcIcuBniYNbWjmeysXEklyw%3D&reserved=0 configuration changes on IDP side doesn't seems to working:
> idp.saml.honorWantAuthnRequestsSigned=true in idp.properties file
The last paragraph on that page seems to be specific about proxying
(i.e., when your IDP *also* acts as an SP)?
> Do I have to enable the flag in <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" AuthnRequestsSigned="false">
Yes, If that SP always signs its authn requests you'd want to set this
to true so that the IDP can tell an unsigned request deviates from
what the metadata said would happen.
-peter
------------------------------
Subject: Digest Footer
--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crarathore%40ptc.com%7C6e5a50b7759549fb50a508d942d11cfd%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C637614289996730263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ei4REL04o1kBdC%2BkmPDrEbipAqJmNHReN9WWZdhw51A%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
End of users Digest, Vol 121, Issue 8
*************************************
More information about the users
mailing list