The idp is ADFS. I don't see a RequestMap block in shibboleth2.xml so I
attached a copy replacing values with MYDOMAIN
Thanks
________________________________
From: Mike Jennings <[email protected]>
Sent: Monday, September 14, 2020 5:59 PM
To: [email protected]
Subject: Re: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
Can you tell me what your RequestMap section looks like in your shibboleth2.xml
file
On Mon, Sep 14, 2020 at 5:57 PM Mike Jennings
<[email protected]<mailto:[email protected]>> wrote:
Nope you should not....
Are you running a shibboleth idp or a adfs
Mike
On Mon, Sep 14, 2020 at 5:18 PM MARTINEZ, ARIEL
<[email protected]<mailto:[email protected]>> wrote:
Tried that, but same result.
In Shibboleth2.xml file, should REMOTE_USER = “eduPersonPrincipalName” be
changed to SHIB_EPPN as well?
Thanks
From: Mike Jennings <[email protected]<mailto:[email protected]>>
Sent: Monday, September 14, 2020 5:14 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
Importance: Low
try setting ShibRequireSession On
Mike
On Mon, Sep 14, 2020 at 5:07 PM MARTINEZ, ARIEL
<[email protected]<mailto:[email protected]>> wrote:
I made the change but it still doesn’t show up in $_SERVER.
Shibboleth.sso/Session now shows SHIB_EPPN for the attribute name after
updating the attribute map xml
Thanks
From: Mike Jennings <[email protected]<mailto:[email protected]>>
Sent: Monday, September 14, 2020 5:02 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
Importance: Low
Yes, after checking the attribute-map.xml file that you sent me, change the
eppn lines to SHIB_EPPN and then reboot the shibd process....
This should pick up the changes in the attribute map and make things work.
Mike
On Mon, Sep 14, 2020 at 5:00 PM MARTINEZ, ARIEL
<[email protected]<mailto:[email protected]>> wrote:
Yes, I looked through the shibd.log initially and it looked normal no errors
that would give a clue to what is happening. I have a test.php file in the vcl
directory and it prints out many variables except for anything related to
Shibboleth. I've attached the attribute-map.xml file.
Thanks
________________________________
From: Mike Jennings <[email protected]<mailto:[email protected]>>
Sent: Monday, September 14, 2020 4:46 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
Have you looked for any errors in the shibd.log or the transaction.logs of the
shibboleth service provider.
Also have you tried to add a php file to dump the data in the vcl directory
that contains
<?php print_r($_SERVER) ?>
and what does that print out
Also can you send me a copy of your attribute-map.xml file
Mike
On Mon, Sep 14, 2020 at 4:35 PM MARTINEZ, ARIEL
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
wrote:
Hi Mike,
Both Shibboleth.sso/Status and Shibboleth.sso/Session indicate that the
Shibboleth SP appears to be running correctly. I can see eppn, mail and
displayname (haven’t included affiliation) in the session after authenticating.
I just can’t figure out why the $_SERVER variable does not have any Shibboleth
data even though the session is established. Because of this, the
authentication in VCL is not working.
I have a .htaccess file in /var/www/html/vcl directory with the following:
Authtype shibboleth
ShibRequireSession off
Require shibboleth
So when I select the configured SSO option in the VCL login, I get redirected
to my identity provider and it gets redirected back to the /vcl webpage but it
doesn’t log in.
Thanks
From: Mike Jennings
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
Sent: Monday, September 14, 2020 11:17 AM
To:
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
Subject: Re: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
Importance: Low
Martinez,
Sorry I am a little late to the game here.
It has been a long time since I have worked with a Shibboleth SP.
I am currently assuming that you have setup the Shibboleth SP on a Apache HTTPS
server.
I am assuming that you can do the initial test correctly
You can test to ensure that the SP is running properly and the surrounding
environment is correct by accessing https://localhost/Shibboleth.sso/Status
from the actual web server machine. You MUST use "localhost" as the hostname or
it WILL NOT WORK by default. If this test is successful, then the software is
ready for further configuration.
You can also access the Status handler from other clients or using a
non-localhost name, but only if you change the acl parameter in the
configuration to permit your client address or remove it entirely to open up
access to anybody. The ACL is present by default because the Status handler can
return some arguably sensitive information about your configuration.
You have the attribute-map.xml configured correctly. You might need to contact
the Shibboleth IdP Administrator to verify he is releasing attributes to your
sp and what values need to be modified in that file.
Thanks,
Mike Jennings
On Fri, Sep 11, 2020 at 7:48 PM MARTINEZ, ARIEL
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
wrote:
Hi Josh,
Thanks for this info. The problem is that there is no 'SHIB_EPPN' in the
$_SERVER array. There is no other Shibboleth related entry other than the shib
session string HTTP_COOKIE.
Not sure how to correct this. How can the required entry be made to be included
in the array?
Thanks
On Sep 11, 2020 5:39 PM, Josh Thompson
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ariel,
Toward the top of initGlobals in utils.php, there is a small block of code
that tests conditions for each authentication method if the user is not logged
in, and if that authentication method's test function returns true, it will
then call that authentication method's authentication function. It's the
"else" block that starts on line 176 of the 2.5.1 release.
The shibauth.php module uses testShibAuth as the test function. All it does
is to check for $_SERVER['SHIB_EPPN'] being set. If it is not set, it will
not attempt to authenticate the user using Shibboleth. An easy way to test
this is to temporarily put a file in the same directory as the main VCL
index.php directory that just has this in it:
<?php
print "<pre>\n";
print_r($_SERVER);
print "</pre>\n";
?>
Don't leave the file in there beyond the testing since it can disclose various
information about your system.
If you aren't seeing 'SHIB_EPPN' in the $_SERVER array, you have found your
problem. If your Shibboleth configuration is using something different than
'SHIB_EPPN', just change what is checked in testShibAuth in shibauth.php.
The VCL php code doesn't log anywhere other than where php errors would be
going. Look in to configuring php errors for httpd to get that set up. My
experience has been that systems generally don't log php errors anywhere by
default.
Josh
On Thursday, September 10, 2020 1:47:09 PM EDT MARTINEZ, ARIEL wrote:
> I have been looking further into the shibauth.php file to see what is
> supposed to happen when a shibboleth login happens. For starters, it
> creates an affiliation in the affiliation table if it does not find one
> from the attributes received from the identity provider. However it doesn't
> seem to be executing that code. It at the very least should have generated
> an error message when trying to automatically create an affiliation if it
> failed.
>
> Is there any way to troubleshoot shibauth.php to see what is happening? Or
> is this particular function logged somewhere in particular?
>
> Thanks.
>
>
> -----Original Message-----
> From: MARTINEZ, ARIEL
> Sent: Sunday, August 30, 2020 1:11 PM
> To:
> '[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>'
>
> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
> Subject: RE: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
>
> I don't know what else to really try because as far as Shibboleth is
> concerned, it appears to be working. So I went to the
> /Shibboleth.sso/Session URL after logging in and the following is
> displayed, I replaced some values that should not be public:
>
> Miscellaneous
> Session Expiration (barring inactivity): 478 minute(s) Client Address:
> (xx.xx.xx.xxx) SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol Identity
> Provider: (idp entity ID)
> Authentication Time: 2020-08-30T16:54:23.787Z Authentication Context Class:
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
> Authentication Context Decl: (none)
>
> Attributes
> affiliation:
> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
> eppn:
> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>;[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
> upn:
> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
>
>
> Unless eppn should not have two values, as far as I can tell, the proper
> values required by VCL are present. In the VCL database affiliation table,
> I have populated an existing VCL Affiliation that is configured to use LDAP
> with the domain.com<http://domain.com><http://domain.com> value under
> shibname. I also tried creating a new
> affiliation setting shibonly to 1
>
> I still get the same behavior where, after selecting the Shibboleth
> authentication method and signing in at my idp, it gets redirected back to
> the /vcl directory to choose an authentication method.
>
>
> -----Original Message-----
> From: MARTINEZ, ARIEL
> Sent: Thursday, August 27, 2020 3:00 PM
> To:
> '[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>'
>
> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
> Subject: RE: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
>
> After login nothing is happening still. So I moved the test.php file from
> the old Shibboleth instructions to my main VCL directory and set the
> conf.php file to redirect to this file after login and the attributes are
> all undefined.
>
> Is this sufficient to say with a high level of certainty that my IDP is not
> sending VCL what it is expecting? Or is the test.php not meant to work that
> way?
>
> Thanks
>
> -----Original Message-----
> From: MARTINEZ, ARIEL
> Sent: Wednesday, August 26, 2020 11:14 AM
> To:
> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
> Subject: RE: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
>
> Hi Josh,
>
> Last question before I try again, there is no shibboleth affiliation in my
> VCL database. So should I be creating a new affiliation for shibboleth and
> populating the shibname field, or should I use the existing LDAP configured
> affiliation and populate its shibname field?
>
> Thanks
>
> -----Original Message-----
> From: Josh Thompson
> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
> Sent: Wednesday, August 26, 2020 11:04 AM
> To:
> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
> Subject: Re: [Suspected SPAM] Re: [EXTERNAL] Re: ADFS SSO Authentication
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found on
pool.sks-keyservers.net<http://pool.sks-keyservers.net><http://pool.sks-keyservers.net>
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCX1vuhwAKCRBX8tBw1209
A8DxAJ96eWpTyUnduFw9TVnbqelq8Xyt2ACfUmfmuBolOE+Agkt6ZfQVJ4HjO48=
=jMJR
-----END PGP SIGNATURE-----
<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:3.0:native:sp:config"
clockSkew="180">
<OutOfProcess tranLogFormat="%u|%s|%IDP|%i|%ac|%t|%attr|%n|%b|%E|%S|%SS|%L|%UA|%a" />
<!--
By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
are used. See example-shibboleth2.xml for samples of explicitly configuring them.
-->
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.-->
<ApplicationDefaults entityID="https://vcl.MYDOMAIN/shibboleth";
REMOTE_USER="eduPersonPrincipalName affiliation uid"
cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">
<!--
Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
Each Application has an effectively unique handlerURL, which defaults to "/Shibboleth.sso"
and should be a relative path, with the SP computing the full value based on the virtual
host. Using handlerSSL="true" will force the protocol to be https. You should also set
cookieProps to "https" for SSL-only sites. Note that while we default checkAddress to
"false", this makes an assertion stolen in transit easier for attackers to misuse.
-->
<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
checkAddress="false" handlerSSL="false" cookieProps="http"
redirectLimit="exact">
<!--
Configures SSO for a default IdP. To properly allow for >1 IdP, remove
entityID property and adjust discoveryURL to point to discovery service.
You can also override entityID on /Login query string, or in RequestMap/htaccess.
Line before > after trust" below: discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF";
-->
<SSO entityID="http://login.MYDOMAIN/adfs/services/trust"; discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF";>
SAML2
</SSO>
<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>
<!-- Administrative logout. -->
<LogoutInitiator type="Admin" Location="/Logout/Admin" acl="127.0.0.1 ::1" />
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
<!-- Status reporting service. -->
<Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
<!-- Session diagnostic service. -->
<Handler type="Session" Location="/Session" showAttributeValues="true"/>
<!-- JSON feed of discovery information. -->
<Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
</Sessions>
<!--
Allows overriding of error template information/filenames. You can
also add your own attributes with values that can be plugged into the
templates, e.g., helpLocation below.
-->
<Errors supportContact="root@localhost"
helpLocation="/about.html"
styleSheet="/shibboleth-sp/main.css"/>
<!-- Example of locally maintained metadata. -->
<!--
<MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>
-->
<MetadataProvider type="XML" validate="true" path="federationmetadata.xml"/>
<!-- Example of remotely supplied batch of signed metadata. -->
<!--
<MetadataProvider type="XML" validate="true"
url="http://federation.org/federation-metadata.xml";
backingFilePath="federation-metadata.xml" maxRefreshDelay="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="fedsigner.pem" verifyBackup="false"/>
<DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
attributeName="http://macedir.org/entity-category";
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
attributeValue="http://refeds.org/category/hide-from-discovery"; />
</MetadataProvider>
-->
<!-- Example of remotely supplied batch of signed metadata. -->
<!--
<MetadataProvider type="XML" validate="true"
url="https://login.MYDOMAIN/FederationMetadata/2007-06/FederationMetadata.xml";
backingFilePath="federationmetadata.xml" maxRefreshDelay="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="fedsigner.pem" verifyBackup="false"/>
<DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
attributeName="http://macedir.org/entity-category";
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
attributeValue="http://refeds.org/category/hide-from-discovery"; />
</MetadataProvider>
-->
<!-- Example of remotely supplied "on-demand" signed metadata. -->
<!--
<MetadataProvider type="MDQ" validate="true" cacheDirectory="mdq"
baseUrl="http://mdq.federation.org"; ignoreTransport="true">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="mdqsigner.pem" />
</MetadataProvider>
-->
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
<!-- Simple file-based resolvers for separate signing/encryption keys. -->
<CredentialResolver type="File" use="signing"
key="sp-signing-key.pem" certificate="sp-signing-cert.pem"/>
<CredentialResolver type="File" use="encryption"
key="sp-encrypt-key.pem" certificate="sp-encrypt-cert.pem"/>
</ApplicationDefaults>
<!-- Policies that determine how to process and authenticate runtime messages. -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
<!-- Low-level configuration about protocols and bindings available for use. -->
<ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
</SPConfig>
