Ipsilon UI templating

The Ipsilon UI is user-configurable with some caveats.

The template files can be found in /usr/share/ipsilon/templates and the CSS and javascript in /usr/share/ipsilon/ui.

The caveat is that these files may be updated upstream between releases and if the packaging system detects local changes then the local files will not be updated. For rpm-based systems a new file, .rpmnew, will need to be examined and potentially merged into the locally-modified file.

CSS

Ipsilon uses PatternFly 2.0 for its UI framework. The Ipsilon-specific configuration is in admin.css and ipsilon.css. Modifying these files directly may be difficult. If custom changes are required then modifying the less files in the upstream source and rebuilding the CSS is probably easier to maintain.

HTML Templates

The HTML templates consist of a number of common files in the root, administrative UI templates in admin, protocol provider-specific files in openid, personal and saml2 and login-specific files in login.

The subdirectory install contains templates used during installation.

Ipsilon uses the python jinja2 engine for HTML templating. This supports some basic conditionals via {%- if %} {%- endif %} blocks, looping via {% for value in values %} and variable substitution via {{ substitute-me }}. See the jinja2 docs for more details.

Customization to functionality in the UI will be limited by what is made available by Ipsilon itself. Some common variables are:

basepath: URI of the idp, e.g. https://ipsilon.example.com/idp

user.fullname: the login name of the authenticated user. name is an alias for fullname

user.is_admin: boolean, true if the user is an Ipsilon administrator

message: error message when errors are raised

providers: list of SAML2 Service provider objects

Ipsilon, HBAC and the pam service

By default Ipsilon configures pam to authenticate using the remote service. This is at least in part because remote already exists on most systems and was easier to setup during initial development.

We see now that an Ipsilon-specific pam service should be used instead. This can be done pretty easily by using the remote service as a template. This will likely be the basis of the Ipsilon-provided service, https://fedorahosted.org/ipsilon/ticket/176

If you are using IPA HBAC then regardless of the service you’ll need to ensure that the users that you want to be able to use Federation have access to the configured pam service on the Ipsilon IdP host. It becomes clear pretty quickly when used with HBAC why a separate Ipsilon-specific pam service is desirable.

info-sssd and pam authentication

We discovered that the info-sssd plugin doesn’t play nicely when the pam auth plugin is used. This is because info-sssd relies on mod_identity_lookup in Apache to lookup the authenticated REMOTE_USER and retrieve the attributes. The pam auth plugin authenticates directly from within Ipsilon so mod_lookup_identity never gets invoked and no attributes are generated.

The solution is to disable the pam auth plugin and use the form plugin instead.

We are going to solve this more gently in the future by providing “login stacks.” Basically a set of known working stacks that can be applied to a given SP as avenues for authentication and info retrieval. We’re not quite there yet.