Missing instrumented class in my tc-config.xml

[Russell Beall]

Hi Keith,

Your step of adding an instrumented class is the correct way to handle such an error, at least from the TC perspective.

We use forceAuthn on a couple SPs but have not seen that error, and that is probably because we also use a short session lifetime on those SPs.

Your ForceAuthnException probably would happen regardless of whether TC is there or not, so this part has to be handled from an IdP settings perspective.  My only advice on that would be to set a short session lifetime using a custom authentication method targeted specifically for those SPs.  I bet there is a better method though, and I would be interested to hear about what that better solution might be if anyone has it taped.

Regards,
Russ.

On Aug 8, 2012, at 9:10 AM, Wessel, Keith William wrote:

> For anyone interested, I've added the reported missing class to my boot jar file so that users who do something crazy like switch NetIDs mid-session will get something more useful than a blank screen. It's not much more useful, but at least they know they broke something:
> 
> OPENSAML::FATALPROFILEEXCEPTION
> Logo
> The system encountered an error at Wed Aug 8 10:50:59 2012
> To report this problem, please contact the site administrator at
> consult at illinois.edu
> .
> Please include the following message in any email:
> opensaml::FatalProfileException at (https://shib-sp-dev.cites.illinois.edu/Shibboleth.sso/SAML2/POST)
> SAML response contained an error.
> Error from identity provider:
> Status: urn:oasis:names:tc:SAML:2.0:status:Responder
> Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
> 
> Seems our developers are happy with anything rather than nothing, so that's where we're leaving it. If anyone has suggestions at a prettier error message, I'd love to hear about them.
> 
> Thanks,
> Keith
> 
> -----Original Message-----
> From: Wessel, Keith William 
> Sent: Tuesday, August 07, 2012 4:34 PM
> To: users at shibboleth.net
> Subject: RE: Missing instrumented class in my tc-config.xml
> 
> Looking in the list archives a little depper and checking my log again, I see that this is the dreaded "Authenticated principal does not match previously authenticated principal" error.
> 
> Our developers got this by using different test NetIDs with forcedAuth enabled within a single IDP session.
> 
> They were trying to handle the case that someone lets an officemate log into the app shortly after they were logged in and did an SP logout.
> 
> So, amending my earlier question, I'm not going to add this class to the boot jar to fix the problem of principals changing. Rather, I'm going to do it so that the user gets something other than a blank screen in their browser which is the current result.
> 
> 
> I'm guessing the below actions from my last message should address this, but I'm still wanting to make sure I add it right. So, my below questions are still out there if someone wants to give them a shot.
> 
> Thanks,
> Keith
> 
> 
> -----Original Message-----
> From: Wessel, Keith William 
> Sent: Tuesday, August 07, 2012 2:55 PM
> To: users at shibboleth.net
> Subject: Missing instrumented class in my tc-config.xml
> 
> Hi,
> 
> We've just had our first SP hit our IDP cluster that has forced authentication enabled, and it looks like they found a missing instrumented class in our tc-config.xml. As this isn't in the tc-config.xml on the wiki either, I thought I should ask before adding it to make sure Terracotta's coaching me right.
> 
> Below is the block from the idp-process.log spit out by Terracotta telling me what to do.
> 
> 1. Is it safe to add this instrumented-class to tc-config.xml?
> 2. Do I need to add any honor-transient tag to the block and mark it as true as is seen in many of the others?
> 3. Is there a reason this sin't in tc-config.xml on the wiki?
> 
> Thanks. Block frm thelog is:
> 
> Attempt to set the field of a shared object to an instance of a non-portable class. This
> unshareable class has not been included for sharing in the configuration.
> 
> For more information on this issue, please visit our Troubleshooting Guide at:
> http://terracotta.org/kit/troubleshooting
> 
> Thread                 : TP-Processor144
> JVM ID                 : VM(35)
> Non-portable field name: edu.internet2.middleware.shibboleth.idp.authn.LoginContext.authnException
> Non-included class     : edu.internet2.middleware.shibboleth.idp.authn.ForceAuthenticationException
> 
> Under most circumstances, you should only be adding classes for your
> application. If you are adding classes for frameworks or code not written by
> you, then you should consider finding a Terracotta Integration Module (TIM)
> that matches the framework you are using.
> 
> As an example, if the non-portable class listed below is
> net.sf.ehcache.CacheManager, you should consider using the ehcache TIM.
> 
> It is also possible that some or all of the classes above are truly
> non-portable, the solution is then to mark the referring field as transient.
> For more information on non-portable classes see the Troubleshooting Guide.
> 
> Action to take:
> 
> 1) Reconfigure to include the unshareable classes
>   * edit your tc-config.xml file
>   * locate the <dso> element
>   * add this snippet inside the <dso> element
> 
>       <instrumented-classes>
>         <include>
>           <class-expression>edu.internet2.middleware.shibboleth.idp.authn.ForceAuthenticationException</class-expression>
>         </include>
>       </instrumented-classes>
> 
>   * if there is already an <instrumented-classes> element present, simply add
>     the new includes inside it
> 
> Thanks,
> Keith
> 
> PS: Scott, I'm starting to think you're right that life would be easier without Terracotta. No, I'm past starting, actually.
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net