Moving back to official repo and a questions on WordPress integration.

[ghost]

Hello,

I'm working on upgrading our server which include moving back to the official repo (instead of the patched one forked from Mitcho repo). I had to dig down further in Shibboleth (which was usually configured by my collegue) as the migration to RedHat 7 had some unexpected surprises which where solved mostly by moving to php-fpm instead of mod_php.

I have some questions if someone could help me but they are not directly related to the plugin, let me know if there is a better place to ask but I guess I could benefit from the experience of other users using Shibboleth / the Shibboleth plugin in the context of WordPress.

1) What do you use in .htaccess? I have added a RewriteCond %{REQUEST_URI} !^/Shibboleth.sso so that I am able to use /Login /Logout on the SP but I also have noticed that it expose alot of data through /Session (data of the user but maybe more than we should show). Do you just explicitely keep /Login /Logout? (or none?)

2) Also, reading more on Shibboleth I think I have found an article that suggested that logout should be done on sp with a redirect for logout on idp (maybe https://wiki.shibboleth.net/confluence/display/CONCEPT/SLOIssues). What would be best practice as logout url in the configs of Shibboleth plugin?

Eric

[ghost]

The upgrade of the plugin itself when smoothly so far.

I'll test some more and familiarise with the new settings (spoof key by ex.) and report if I see any issue.

Thanks for the work.

[jrchamp]

I usually add a rule near the top so that it stops trying to modify Shibboleth.sso paths immediately.

# Don't touch Shibboleth URLs
RewriteRule ^Shibboleth\.sso - [L]

You need the Login and Logout for the functionality they provide and it's normal for Session to show information, but not the attribute values. Within the plugin, I usually redirect the Logout back to the site home page, such as: https://example.com/Shibboleth.sso/Logout?return=https://example.com/

Single Log Out (SLO) is largely a losing battle. You can't destroy all the SP tokens that were generated (because you don't know where else the user logged in) from a single IDP session, so we've tried user education with some success. In general, options such as completely closing the browser, deleting the cookies, using incognito windows are more effective. Plus, the lifetime is limited on the sessions, so usually within a few hours the sessions have expired.

[ghost]

Thanks for the help and info.

In my case, /Session does show attributes, I have anonymised the data but it looks like this, I guess I will have to double check that.

Miscellaneous Session Expiration (barring inactivity): 479 minute(s) Client Address: removed SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol Identity Provider: https://our-idp/idp/shibboleth Authentication Time: 2018-04-25T19:31:46.542Z Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Authentication Context Decl: (none)

Attributes our-attribute-xyz: removed our-attribute-xyz: removed our-attribute-xyz: removed commonName: removed email: removed our-attribute-xyz: removed givenName: removed our-attribute-xyz: removed our-attribute-xyz: removed preferredlocale: fr_CA our-attribute-xyz: null roles: \; sn: removed uid: removed

[jrchamp]

I'm guessing showAttributeValues is enabled. It is not recommended to have that enabled in production. It is most likely in the shibboleth2.xml and probably looks like this:

<Handler type="Session" Location="/Session" showAttributeValues="true"/>

[ghost]

Yes indeed. Thanks for the pointer.

[ghost]

I close the issue, thanks for the help.