Is Federation Putting you at Risk? Presenter: Dan Dagnall – Chief Operating Officer, Fischer International Identity, LLC

Overview

Session Overview What is Federation? How does Federation work? IdP SP Evaluate your risk Best practices to increase security

Discussion Question  Where are the potential risks within your shibboleth federation?  Is your federation putting you at risk?  Or the better question…

What is Federation?  A trust model, whereas access to Service Providers (“SPs”) is controlled by authenticating users with local (organizational) credentials to the Identity Provider. (the ”IdP”)  SPs are configured to “trust” inbound assertions from the IdP and if the IdP says let user XYZ into your application, the SP obliges as long as….

Properly formed assertion…  The inbound attribute payload provided by the IdP meets the SP’s metadata requirements.  SP defines the assertion parameters to ensure proper identification of the inbound user occurs  But who or what is defining and ensuring the information used is correct?

What Shibboleth looks like to many..

What happens inside the Identity Provider?

Seems painless right? But… In a default shibboleth deployment, the credentials within the login.config file are stored in clear text at rest within the IdP configuration. Shellshock or malicious admins can easily compromise your federation or your attribute store if you deploy default shibboleth.

Is there a way to fix this? Replace the JAAS module with one that allows for encryption of credentials at rest. This is the way to address this issue. Research potential vendors that have replaced the JAAS module already Fischer recognized this and ripped out the default JAAS module. Our default deployment replaces the stored credentials with variables, and the actual values are resolved during the secure retrieval of attributes.

What about other risks…  As an administrator, with direct access to the attribute store, I can very easily manipulate a user’s identity to mask the identity of the real user accessing the SP.  Especially if an open source ldap store is used, given it’s loose enforcement of unique values.

Is there a way to fix this one? Lock down your attribute store(s) with event detection mechanisms such as triggers, or delta processes that execute on a regular basis. You should be monitoring any attribute/value pair that equates to access to some SP. You need to do this constantly, and remediate any modification immediately. Define a few privileged accounts, and allow admins to check those accounts out, as opposed to the user maintaining admin rights with their campus ID. Enable add-ons such as uApprove that provides the user with visabilty to the attributes being passed to the SP.

Is there a way to fix this one? (cont’d) Introduce automated provisioning and synchronization processes from attribute’s source of truth, to the user’s actual identity attribute store. Automation at this layer will enable your organization to perform the proper uniqueness checks against all values in the directory that manually manipulating end user objects does not provide.

Best Practices to thwart potential risk  Use your identity management system.  Introduce automation for your sensitive data processes.  Introduce policy-driven access controls. It’s works the same every time. Eliminates manual manipulation of attributes associated with identifying the user external to your campus.  Do not make identity mgt and federation administration mutually exclusive

Help Us Improve and Grow Thank you for participating in today’s session. We’re very interested in your feedback. Please take a minute to fill out the session evaluation found within the conference mobile app, or the online agenda.