Discussion:
Viewing attribute assertion values on the SP
Mark K. Miller
2010-03-25 14:23:26 UTC
Permalink
What's the easiest way on the SP to view the values of the attributes in
the assertion from the IdP? Just to make things more fun, the SP is
actually in production and delivering services. So, we wouldn't want our
observation to hinder that at all.

I did some searching in the wiki, but the closest thing I saw might be
here: https://spaces.internet2.edu/display/SHIB/LogFiles However, that
page seems a 'little thin' on specifics of how to actually change logging
levels or where assertions actually show up on the SP.

Thanks!
Scott Cantor
2010-03-25 16:58:08 UTC
Permalink
Post by Mark K. Miller
What's the easiest way on the SP to view the values of the attributes in
the assertion from the IdP? Just to make things more fun, the SP is
actually in production and delivering services. So, we wouldn't want our
observation to hinder that at all.
Depends what you're trying to find out. If you want to know what the SP
cached, just use the /Session handler and turn on the option to show the
values.
Post by Mark K. Miller
I did some searching in the wiki, but the closest thing I saw might be
here: https://spaces.internet2.edu/display/SHIB/LogFiles However, that
page seems a 'little thin' on specifics of how to actually change logging
levels or where assertions actually show up on the SP.
If you want the XML dumped, the category to adjust is shown in the relevant
logging configuration file.

-- Scott
Mark K. Miller
2010-03-25 19:02:03 UTC
Permalink
Post by Scott Cantor
Post by Mark K. Miller
What's the easiest way on the SP to view the values of the attributes in
the assertion from the IdP? Just to make things more fun, the SP is
actually in production and delivering services. So, we wouldn't want our
observation to hinder that at all.
Depends what you're trying to find out. If you want to know what the SP
cached,
Yeah, I think that's all I'm going to need. Just some way of knowing the
for attributeA the value in the assertion was xyz.
Post by Scott Cantor
just use the /Session handler and turn on the option to show the
values.
So, then this is just something like adding

showAttributeValues="true"

in an appropriate session handler stanza of the shibboleth2.xml config
file, right? Once that's setup right where are these values actually
shown?
Post by Scott Cantor
Post by Mark K. Miller
I did some searching in the wiki, but the closest thing I saw might be
here: https://spaces.internet2.edu/display/SHIB/LogFiles However, that
page seems a 'little thin' on specifics of how to actually change logging
levels or where assertions actually show up on the SP.
If you want the XML dumped, the category to adjust is shown in the relevant
logging configuration file.
I'm guessing this is probably overkill.
Post by Scott Cantor
-- Scott
Thanks!

Max
Scott Cantor
2010-03-25 20:07:07 UTC
Permalink
Post by Mark K. Miller
Yeah, I think that's all I'm going to need. Just some way of knowing the
for attributeA the value in the assertion was xyz.
It will tell you what the result of extraction/decoding, filtering, and
serializing the values is, which isn't the same thing as what was in the
assertion. Only the log can tell you that.
Post by Mark K. Miller
So, then this is just something like adding
showAttributeValues="true"
in an appropriate session handler stanza of the shibboleth2.xml config
file, right? Once that's setup right where are these values actually
shown?
On the page returned by requests to the /Session handler.

-- Scott
Mark K. Miller
2010-03-25 21:22:00 UTC
Permalink
Post by Scott Cantor
Post by Mark K. Miller
Yeah, I think that's all I'm going to need. Just some way of knowing the
for attributeA the value in the assertion was xyz.
It will tell you what the result of extraction/decoding, filtering, and
serializing the values is,
Uh, extraction/decoding, filtering, and serializing; oh my! What's all
that mean?!?!?
Post by Scott Cantor
which isn't the same thing as what was in the
assertion. Only the log can tell you that.
Maybe I'm not asking this quite correctly, then. What's important is that
I find out what the SP 'thinks' it received as the value of an attribute.
Post by Scott Cantor
Post by Mark K. Miller
So, then this is just something like adding
showAttributeValues="true"
in an appropriate session handler stanza of the shibboleth2.xml config
file, right? Once that's setup right where are these values actually
shown?
On the page returned by requests to the /Session handler.
Oh, you mean on the page that the users sees? That's probably not going
to be useful. As I mentioned originally, its important to not have our
observation make any change in functionality seen by the users.
Post by Scott Cantor
-- Scott
Peter Schober
2010-03-25 23:52:26 UTC
Permalink
Post by Mark K. Miller
Post by Scott Cantor
On the page returned by requests to the /Session handler.
Oh, you mean on the page that the users sees? That's probably not going
to be useful. As I mentioned originally, its important to not have our
observation make any change in functionality seen by the users.
No. There is no reason for anyone to access this handler usually, and
if you don't even know its URL I seriously doubt your users will.
Hence there's nothing to interfere with your production site.
You don't even have to restart shibd or httpd or anything. Just
change 'false' to 'true' in the aforementioned spot and access the
correct URL at your SP.

Unless you've changed the handlerURL (see the eponymous XML attribute
on the <Sessions> element in your shibboleth2.xml and in the official
documentation) the session handler is available by accessing
https://your.host.example.edu/Shibboleth.sso/Session after having
initiated a session with that SP.

Alternatively you could just dump the webserver's environment with a
scripting language or trivial CGI script. But it doesn't get any
easier than setting showAttributeValues to 'true'.
-peter
Scott Cantor
2010-03-26 03:57:41 UTC
Permalink
Post by Mark K. Miller
Uh, extraction/decoding, filtering, and serializing; oh my! What's all
that mean?!?!?
extract - turn incoming SAML into raw attributes
decode - transform SAML Attribute elements into internal objects
filter - decide what to keep and what to toss
serialize - flatten values into formats suitable for application use

https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeRetrieval

If what was in the XML was directly relevant to an application, most of the
SP wouldn't be needed.
Post by Mark K. Miller
Maybe I'm not asking this quite correctly, then. What's important is that
I find out what the SP 'thinks' it received as the value of an attribute.
That's my point. The SP "receives" SAML, which is only generally seen in the
log. The SP "provides to applications" the results of a process that
sometimes tosses out or ignores a lot of the SAML.

If you're debugging an application, it's really the latter that matters, but
sometimes the former is needed to prove to a stubborn IdP that they aren't
sending what they think.
Post by Mark K. Miller
Post by Scott Cantor
On the page returned by requests to the /Session handler.
Oh, you mean on the page that the users sees? That's probably not going
to be useful. As I mentioned originally, its important to not have our
observation make any change in functionality seen by the users.
Peter answered that.

If you're trying to find out what data is present for somebody other than
you (or somebody you can login as), there's no external way to do that. The
adjusted log is the only source for that.

-- Scott

Continue reading on narkive:
Loading...