Debugging scripted attributes?

[Losen, Stephen C. (scl)]

Hi Rod,

Thanks for the suggestions.

I can see your point that a script exception should terminate attribute release.  But is there no way to at least log that the exception was caused by a script and maybe even which attribute it was defining?  Or perhaps generate a fuller stack trace?

The script that caused me grief is rather long and complicated, and we need to update it on occasion.

The script generates an attribute called "authService" which is a list of services that the user is authorized to use (such as BOX or various software download services or Qualtrics, etc.)  The logic is very complicated involving numerous LDAP attributes.  And each service has its own rather convoluted rules.  Downstream the "authService" attribute is used in attribute filters to control the release of other attributes.  Yes it would be nice if the SPs would do this logic, but in reality that is often not possible.  For example, if we release "mail" to BOX then you get in, otherwise you don't. The BOX SP is not aware of the gnarly details of our contract, so that means our IDP has to enforce it.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu    434-924-0640

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Rod Widdowson
Sent: Wednesday, November 30, 2016 8:52 AM
To: 'Shib Users'
Subject: RE: Debugging scripted attributes?

> So I am wondering how other folks detect problems in attribute scripts and debug them.  Can I set something in logback.xml ?

There is a dent in the wall by my desk from where I have beaten my head against it chasing up equivalent issues.  There is nothing
that can be done to help you inside the IdP.

But..... Some kind soul documented, quite some time ago, how to add logging to your script[1], so you can use "printf debugging"
without having to debug the code to add debugging to your script.


[1]
https://wiki.shibboleth.net/confluence/display/IDP30/ScriptedAttributeDefinition#ScriptedAttributeDefinition-LoggingWithinaScript

> Also, it seems a bit harsh to completely derail attribute release for a script error like this.  
> Couldn't it be handled a bit more gracefully?  Perhaps just bail on the attribute that the 
> script is defining, but continue the release process?

Nice idea but we couldn't make it "safe".  You might be using the presence of an attribute to disallow attribute release further
down the line and a failure (even with noise) could lead to information leakage.  

The general idea is that you debug the resolver script once (and that is painful) and then it works. If it fails in production n
that is serious and you need to know about it.

Sorry to not be more positive.

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net