-
Notifications
You must be signed in to change notification settings - Fork 490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shibboleth: tooling for debugging SAML assertions #2916
Comments
- Some debugging relates to groups #105 - Some code cleanup.
I just pushed f901d9f to the 2939-shib branch. I decide that more logging is really what sysadmins need so I added more, including information about Shibboleth groups (all groups really). This is not controlled by a database setting anymore. As I hinted at above, you can just change the logging level on the fly by following http://guides.dataverse.org/en/4.2.3/developers/debugging.html . Mostly for @kcondon 's benefit when testing all of #2939 I left the logging level at "info" but we can reduce some or all of it to "fine" to only show by default what's most important or interesting. As of this writing, here's how it looks when a new user logs in via Shib and clicks the button to confirm the creation of the account:
When I was working on this I was reminded of http://stackoverflow.com/questions/30193117/iterate-through-all-servletrequest-attributes#comment49933342_30193117 and http://shibboleth.1660669.n2.nabble.com/Why-doesn-t-Java-s-request-getAttributeNames-show-Shibboleth-attributes-tp7616427p7616591.html but I couldn't figure out how to print out Also, #105 about a GUI to see what groups you are in is out of scope for the current effort underway in #2939 but I did add a little bit of debug output which you can see in the last line of output above. I think this will come in handy when Shib groups are tested in #1533 (or whatever issue we use to verify that institutional groups developed in #1401 are still working). A lot of the debugging code is in edu.harvard.iq.dataverse.Shib but I'm hoping to rename this to edu.harvard.iq.dataverse.authorization.providers.shib.ShibPage to get it out of the default package and get in line with our naming convention for backing beans. Once that is done I can document how to increase the logging level and just refer to the whole "shib" package. |
I like where you're going with this, @pdurbin. :) |
@bencomp please try out the war file at https://build.hmdc.harvard.edu:8443/job/shibtest.dataverse.org-build-2939-shib/1/edu.harvard.iq$dataverse/artifact/edu.harvard.iq/dataverse/4.3/dataverse-4.3.war and let me know what you think. I'm happy to make adjustments. I'm passing this issue to QA. Shibboleth debugging is no longer tied to a boolean in the database. Rather than showing stuff in the UI which is confusing for users, I added more logging and documented how you can control the verbosity at http://guides.dataverse.org/en/2939-shib/installation/shibboleth.html#debugging The fix is in pull request #3025. |
In af72a7b I turned down the Shib logging. As @kcondon and I discussed, the way to turn it back up is at runtime as described at http://guides.dataverse.org/en/2939-shib/installation/shibboleth.html#debugging |
OK, works, closing. |
When chatting with @ecr2c @shlake and others about troubles they've had getting Shibboleth configured I mentioned over the phone and later in a support ticket that there's an undocumented database setting that may help them reason about assertions being made via SAML by their Identity Provider by increasing logging in the Glassfish's server.log.
This issue is about either making that (or another) database setting official by documenting it or at least documenting how to increase the logging level as explained at http://guides.dataverse.org/en/4.2.3/developers/debugging.html (as well as making sure debugging lines are logged at appropriate levels).
The text was updated successfully, but these errors were encountered: