A Rails app with Shibboleth is not as easy to test as an app with say LDAP authentication.
Functional tests work, but at a cost: the ENV name changes. In production (mod_passenger) the surname might be 'sn'. In test it is 'HTTP_SN'.
Sometime people write some env-driven if blocks to stub a user's login in development. Each time you need to change user's data you need to fix the controller.
The solution is:
outfactor the data fetching from ENV is a custom class;
Short things first: it is not worth. There are easier ways to have
Ruby on Rails and SAML2 auth to go hand in hand, with single
logout included.
The hard part is not the Shibboleth one: you just need to add a
Notify
The matter is this setup is completely against a few Rails' conventions:
SOAP support has been dropped from Rails since version 1.2;
you are not expect to tweak with arbitrary session objects which in turn means:
you can't use the trusted cookie session store but you have to switch to the
harder database-backed session store, which by the way you need to
customize a bit to hold the Shib-Session-ID data;
you need to fight against encrypted sessions, the default.
In the Shibboleth IdP it's possible to enable the
impersonation intercept
to enable help desk to impersonate users.
The impersonation is an amazing feature very well designed.
You can enable it in three steps:
enable the module;
add a p:postAuthenticationFlows="#{ {'impersonate'} }" attr to the
SAML2 property to the relying party list involved
(relying-party.xml);
configure it on conf/access-control.xml (legacy configuration file
in conf/intercept is useless).
The documentation proposes a workflow where a help desk operator has to be
authorized to impersonate johndoe user by adding the johndoe value to a
certain operator's attribute.
If your requirements allow any help desk operator to impersonate any user, the
configuration can be simply:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The impersonation event is logged on the IdP. But if you want to let the SP to
know about it, you can leverage the "populate the impersonated principal name
into the attached SubjectContext" phase of the module. What you need is a
acript that picks the added Subject and turns it to an attribute:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Of course the attribute format can be embedded in the declaration or be pulled in from a property file in conf/attributes/custom:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters