Properly test a Rails app with shibboleth auth

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;
• use system test to mock the class above.

Some source code on github shows you the details.

Check the system test:

test/system/login_users_test.rb

The translation class is in:

app/lib

Rails6 shibboleth single logout through notify

This is a proof of concept of a Ruby on Rails application with Shibboleth authentication, pure rails session and a working single sign off.

This application follows: SLOWebappAdaptation .

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.

If nevertheless interested, have a look at source code on github.

Shibboleth-Idp4 impersonation: fetch the impersonating user as an attribute.

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:

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:

Add it to attribute-resolver.xml:

Of course the attribute format can be embedded in the declaration or be pulled in from a property file in conf/attributes/custom: