[LON-CAPA-admin] Single Sign On
Raeburn, Stuart
raeburn at msu.edu
Thu Mar 25 10:25:58 EDT 2021
Hello Paul,
My recommendation would be to take a look at the ApplicationDefaults section in /etc/shibboleth2.xml.
The SP entityID needs to match what is expected by the IdP.
The REMOTE_USER should be set to the attribute to be used to identify the authenticated user, e.g.,
<ApplicationDefaults id="default" policyId="default"
entityID="https://federate.bsu.edu/shibboleth"
REMOTE_USER="eppn persistent-id targeted-id"
>From the LON-CAPA Domain Coordination manual (section 4.2):
"REMOTEUSER is used to pass on the primary identifier of the authenticated user. It should be set to match an attribute or alias defined in the attribute-map.xml file. LON-CAPA uses this value ($r->user in the mod_perl environment) as the username of the user."
As noted here: mail.lon-capa.org/pipermail/lon-capa-admin/2012-July/002609.html
"for Shibboleth SSO to work with LON-CAPA, lonshibauth.pm and lonshibacc.pm need to have been installed in /home/httpd/lib/perl/Apache and also /home/httpd/html/adm/sso needs to have been installed."
In LON-CAPA's apache config file: /etc/httpd/conf/loncapa_apache.conf (on CentOS/RHEL/Scientific Linux/Oracle Linux) you'll find:
<IfModule mod_shib>
PerlAuthenHandler Apache::lonshibauth
PerlSetVar lonOtherAuthen yes
PerlSetVar lonOtherAuthenType Shibboleth
</IfModule>
and
<Location /adm/sso>
<IfModule mod_shib>
AuthType shibboleth
ShibUseEnvironment On
ShibRequestSetting requireSession 1
ShibRequestSetting redirectToSSL 443
require valid-user
PerlAuthzHandler Apache::lonshibacc
PerlAuthzHandler Apache::lonacc
</IfModule>
<IfModule !mod_shib>
PerlTypeHandler Apache::lonnoshib
</IfModule>
</Location>
The lonshibauth.pm module will redirect a user requiring Single Sign On via Shibboleth to a URL -- /adm/sso -- on the server which is configured to use that service.
The lonshibacc.pm module is an authorization handler used to remove trailing @internet domain from the Shibboleth-authenticated username (e.g., @bsu.edu).
After removing @bsu.edu from $r->user, the handler will return DECLINED so that
lonacc.pm can be invoked as the next authorization handler.
The subroutine in /home/httpd/lib/perl/Apache/lonacc.pm used for LON-CAPA session management for SSO-authenticated users (both Shibboleth and CAS) is: sso_login(). The call to that routine occurs early in the lonacc.pm handler() routine, immediately after retrieving a LON-CAPA session handle for an unexpired LON-CAPA session, based on a session cookie (if there is one) included in the browser's request.
The sso_login() routine in lonacc.pm does not write much to the logs. If $r->user was set (i.e., the user was authenticated by Shibboleth), and the value passes a regexp check that it could be a valid username, then LON-CAPA will check whether that user exists in the domain. If so, this will be logged in /home/httpd/perl/logs/lonnet.log:
SSO authorized user <username>
You could add some more calls to &Apache::lonnet::logthis() to log other things to /home/httpd/perl/logs/lonnet.log to try to figure out what is going.
After making changes do:
service httpd reload
Stuart Raeburn
LON-CAPA Academic Consortium
________________________________________
From: Neubauer, Paul <pneubauer at bsu.edu>
Sent: Thursday, March 25, 2021 8:44 AM
To: lon-capa-admin at mail.lon-capa.org; Raeburn, Stuart
Subject: Re: Single Sign On
Hi Stuart (or anyone else who has any ideas for me),
We've continued trying to track this down, without notable success.
What routine in lon-capa handles the attributes sent by the IdP and decides whether it matches a valid user? Is there any log setting to capture the attributes sent by our IdP? So far, we have not found any settings in /etc/shibboleth/shibd.logger that capture the attributes received into either /var/log/shibboleth/shibd.log or /var/log/shibboleth/transaction.log. Do you know of any such setting? Alternatively, is there any lon-capa log that might be informative with regard to who logs in and when or how?
Thanks,
Paul
________________________________
From: Neubauer, Paul <pneubauer at bsu.edu>
Sent: Wednesday, March 24, 2021 9:38 AM
To: lon-capa-admin at mail.lon-capa.org <lon-capa-admin at mail.lon-capa.org>; Raeburn, Stuart <raeburn at msu.edu>; Neubauer, Paul <pneubauer at bsu.edu>
Subject: Re: Single Sign On
Hi Stuart and all,
As Stuart commented on Sunday, "the standard advice is to check the MetadataProvider element(s) in your shibboleth2.xml file." Our guy who is spearheading the replacement of our IdP (Identity Provider) came up with the following change to our MetadataProvider element:
<MetadataProvider type="XML" uri="https://federate.bsu.edu/FederationMetadata/2007-06/FederationMetadata.xml<https://urldefense.com/v3/__https://federate.bsu.edu/FederationMetadata/2007-06/FederationMetadata.xml__;!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtLz6CjS0w$>"
backingFilePath="metadata/federate.bsu.edu.xml" reloadInterval="7200"/>
I have to admit that I don't understand the point of the differences. My ignorance may be curable, but as of now we only have about a week to make it work, so educating me about the ins and outs of SSO is not our highest priority right now. We've been "experimenting" every morning at 6am. At this time, using that new version of shibboleth2.xml, I do successfully get redirected to our login page and I can tell I have succeeded at the IdP end of the operation because I get the push to my phone for our two-factor authentication. So far, so good.
Unfortunately (you knew this was coming, right?) the next thing I see is:
-------------------------------------------------
Forbidden
You don't have permission to access /adm/sso on this server.
-------------------------------------------------
Some googling reveals that I had asked exactly this question on this list in December, 2017: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.lon-capa.org%2Fpipermail%2Flon-capa-admin%2F2017-December%2F003310.html&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396339240%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yA0DUUedb5cKoNazDBH4LNogE8tU3GIfmLLJwndx5yE%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fmail.lon-capa.org*2Fpipermail*2Flon-capa-admin*2F2017-December*2F003310.html&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396339240*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=yA0DUUedb5cKoNazDBH4LNogE8tU3GIfmLLJwndx5yE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtIwuuSo3g$>
I got no answer on the list at that time and I don't recall even asking the question, let alone how we solved it, or even who solved it.
I naïvely suspected that the new IdP is providing different data to lon-capa, but I am assured that the "assertions and attributes haven't changed." I don't know how to capture whatever our IdP is actually providing to lon-capa, so I don't know how to compare the new IdP data to the old. Is that logged somewhere? What routine handles the authentication within lon-capa?
Does anyone have a clue for the clueless (me)?
Thanks,
Paul
From: LON-CAPA-admin <lon-capa-admin-bounces at mail.lon-capa.org> on behalf of Neubauer, Paul via LON-CAPA-admin <lon-capa-admin at mail.lon-capa.org>
Sent: Sunday, March 21, 2021 6:01 PM
To: lon-capa-admin at mail.lon-capa.org <lon-capa-admin at mail.lon-capa.org>; Raeburn, Stuart <raeburn at msu.edu>
Subject: Re: [LON-CAPA-admin] Single Sign On
Hi Stuart,
Sorry. Yes it is odd. I did a screenshot instead of a text copy and then retyped the message from that. That's the cause of the "lonn-capa01" instead of "lon-capa01" (assuming you meant the double-n in "lonn" as what is odd). (I also have to apologize for the HTML mail instead of plain text I think I've corrected both now.)
"lon-capa01.aws.bsu.edu" is the canonical name of the system (as we have it hosted on Amazon Web Services) and "lon-capa.bsu.edu" is an alternate name. So far, that has not been a problem.
Anyway, the file shibboleth2.xml.old is the (copy of the) original (which we have now reverted to) and shibboleth2.xml.new is the version of shibboleth2.xml that was in use when we got the error.
A diff of the two files:
diff shibboleth2.xml.old shibboleth2.xml.new
51c51
< <SSO entityID="https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396349225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ded1RdH6pxP6Ls05ALy%2BIltEWoMEHvnSKj3%2Fnkvh1t0%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fshibboleth.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396349225*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Ded1RdH6pxP6Ls05ALy*2BIltEWoMEHvnSKj3*2Fnkvh1t0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtJMzrEUJw$>">SAML2 SAML1</SSO>
---
> <SSO entityID="https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffederate.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396349225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tGupHkVFNYdwehnfQaU62awnv8ghjQyQCSPORA%2Fhmjc%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Ffederate.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396349225*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=tGupHkVFNYdwehnfQaU62awnv8ghjQyQCSPORA*2Fhmjc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUl!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtL3SdFlBw$>">SAML2 SAML1</SSO>
82c82
< file="metadata/shibboleth.bsu.edu.xml"/>
---
> file="metadata/federate.bsu.edu.xml"/>
shows that the only changes were from shibboleth.bsu.edu to federate.bsu.edu and the result of the grep that I included in the original message showed that I changed all instances of the string 'shibboleth.bsu.edu' so how did it get that the identity provider ought to be 'https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396349225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ded1RdH6pxP6Ls05ALy%2BIltEWoMEHvnSKj3%2Fnkvh1t0%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fshibboleth.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396349225*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Ded1RdH6pxP6Ls05ALy*2BIltEWoMEHvnSKj3*2Fnkvh1t0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtJMzrEUJw$>'? There were no instances of that string anywhere in /etc (let alone /etc/shibboleth).. If the message had said that it was unable to locate identity provider (https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffederate.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396349225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tGupHkVFNYdwehnfQaU62awnv8ghjQyQCSPORA%2Fhmjc%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Ffederate.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396349225*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=tGupHkVFNYdwehnfQaU62awnv8ghjQyQCSPORA*2Fhmjc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUl!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtL3SdFlBw$>) I would be a lot less puzzled.
Thanks,
Paul
From: LON-CAPA-admin <lon-capa-admin-bounces at mail.lon-capa.org> on behalf of Raeburn, Stuart via LON-CAPA-admin <lon-capa-admin at mail.lon-capa.org>
Sent: Sunday, March 21, 2021 4:55 PM
To: lon-capa-admin at mail.lon-capa.org <lon-capa-admin at mail.lon-capa.org>
Subject: Re: [LON-CAPA-admin] Single Sign On
Hello Paul,
This line is odd:
"Identity provider lookup failed at (https:lonn-capa01.aws.bsu.edu/adm/sso)"
I would expect that to be lookup failed at:
https://lon-capa01.aws.bsu.edu/adm/sso<https://urldefense.com/v3/__https://lon-capa01.aws.bsu.edu/adm/sso__;!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtJtExTeIw$>
IP address: 34.204.137.158 points at lon-capa.bsu.edu
and lon-capa01.aws.bsu.edu has IP address: 34.204.137.158
If you see: "Unable to locate metadata for identity provider" the standard advice is to check the MetadataProvider element(s) in your shibboleth2.xml file.
Stuart Raeburn
LON-CAPA Academic Consortium
________________________________________
From: LON-CAPA-admin <lon-capa-admin-bounces at mail.lon-capa.org> on behalf of Neubauer, Paul via LON-CAPA-admin <lon-capa-admin at mail.lon-capa.org>
Sent: Sunday, March 21, 2021 2:30 PM
To: list about administration and system updating(lon-capa-admin at mail.lon-capa.org)
Subject: [LON-CAPA-admin] Single Sign On
Hi all,
We (Ball State University) are in the process of updating our identity provider. We are rolling in the changes so individual systems are being moved from using "shibboleth.bsu.edu" to using "federate.bsu.edu". It is lon-capa's turn.
I found all the files that referenced "shibboleth.bsu.edu" and copied them to a different location:
cp /etc/shibboleth/attribute-map.xml /root/sso/attribute-map.xml.old
cp /etc/shibboleth/shibboleth2.xml /root/sso/shibboleth2.xml.old
cp /etc/shibboleth/metadata/shibboleth.bsu.edu.xml /root/sso/shibboleth.bsu.edu.xml
I then made copies of the two .old files as .new and edited them to replace "shibboleth.bsu.edu" with "federate.bsu.edu"
I also got the new metadata (with wget https://federate.bsu.edu/FederationMetadata/2007-06/FederationMetadata.xml<https://urldefense.com/v3/__https://federate.bsu.edu/FederationMetadata/2007-06/FederationMetadata.xml__;!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtLz6CjS0w$>) and saved it as federate.bsu.edu.xml
This morning I stopped shibd, copied the .new files to /etc/shibboleth/ and federate.bsu.edu.xml to /etc/shibboleth/metadata/
I checked for "shibboleth.bsu.edu":
[root at lon-capa01 ~]# grep -H -r -i 'shibboleth.bsu.edu' /etc
[root at lon-capa01 ~]#
which shows that I had eliminated all references to it.
I restarted shibd and when I tried to log in, I got:
---------------------------------
Unknown or unusable identity provider
The identity provider supplying your login credentials is not authorized for use with this service or does not support the necessary capabilities.
To report this problem, please contact the site administrator at security at bsu.edu.
Please include the following error message in any email:
Identity provider lookup failed at (https:lon-capa01.aws.bsu.edu/adm/sso)
EntityID: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396349225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ded1RdH6pxP6Ls05ALy%2BIltEWoMEHvnSKj3%2Fnkvh1t0%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fshibboleth.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396349225*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Ded1RdH6pxP6Ls05ALy*2BIltEWoMEHvnSKj3*2Fnkvh1t0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtJMzrEUJw$>
opensaml::saml2md::MetadataException: Unable to locate metadata for identity provider (https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396349225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ded1RdH6pxP6Ls05ALy%2BIltEWoMEHvnSKj3%2Fnkvh1t0%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fshibboleth.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396349225*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Ded1RdH6pxP6Ls05ALy*2BIltEWoMEHvnSKj3*2Fnkvh1t0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtJMzrEUJw$>)
---------------------------------
For some reason it was still looking for the EntityID https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fshibboleth.bsu.edu%2Fsso&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396359220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qn0%2F%2BkrY6uEO5Pwq6%2BzApY1PSf3Y%2F15S00bfM%2FSHbts%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fshibboleth.bsu.edu*2Fsso&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396359220*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=Qn0*2F*2BkrY6uEO5Pwq6*2BzApY1PSf3Y*2F15S00bfM*2FSHbts*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtILcV_u_g$>
I did a system reboot but got the same thing.
I reverted to the old files and we are working, but that will only last a couple of weeks before our cert expires for our old identity provider site and it goes down.
I am totally lost. is there somewhere else with shibboleth configuration data?
Thanks,
Paul
_______________________________________________
LON-CAPA-admin mailing list
LON-CAPA-admin at mail.lon-capa.org
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.lon-capa.org%2Fmailman%2Flistinfo%2Flon-capa-admin&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396359220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mpktbZjY0DGma4HNz51ndCTwqalkjOkGmvJ79S1IJj8%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fmail.lon-capa.org*2Fmailman*2Flistinfo*2Flon-capa-admin&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396359220*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=mpktbZjY0DGma4HNz51ndCTwqalkjOkGmvJ79S1IJj8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtIBL3FgoA$>
_______________________________________________
LON-CAPA-admin mailing list
LON-CAPA-admin at mail.lon-capa.org
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.lon-capa.org%2Fmailman%2Flistinfo%2Flon-capa-admin&data=04%7C01%7Cpneubauer%40bsu.edu%7C23e56acc816e48334a4208d8eeca2c4c%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C637521899396359220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mpktbZjY0DGma4HNz51ndCTwqalkjOkGmvJ79S1IJj8%3D&reserved=0<https://urldefense.com/v3/__https://nam12.safelinks.protection.outlook.com/?url=http*3A*2F*2Fmail.lon-capa.org*2Fmailman*2Flistinfo*2Flon-capa-admin&data=04*7C01*7Cpneubauer*40bsu.edu*7C23e56acc816e48334a4208d8eeca2c4c*7C6fff909f07dc40da9e30fd7549c0f494*7C0*7C0*7C637521899396359220*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=mpktbZjY0DGma4HNz51ndCTwqalkjOkGmvJ79S1IJj8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!HXCxUKc!mwxaXXgMT_dJr9y4bdf14pDe3QVy-O4vf4ganh6meYGLrRNCXMI7vtIBL3FgoA$>
More information about the LON-CAPA-admin
mailing list