TIIME 2015 Session 1: Non-Web SSO

Convener: Gerben Venekamp

Abstract: The system of offline Single Sign-On interfaces where a user just has to login once in order to gain access to the whole network of interfaces. Interfaces with a very high trust level as they are all based locally which use passwords as user authorization.

Tags: Non-Web SSO, SAML ECP, Moonshot

Notes

SSH Key proxying

Cheap to deploy, but not so cheap to the user himself. There are very smart scientists but no smart computer-scientists.

Non-web SSO

• Trusting some interface that is more local to you. As it is more local in scope you trust it because you have more control.
• FIDO-based identities. It’s key based encrypted authentication, it's Javascript, it needs a browser.
• If you stick with SAML ECP, you will have a password.
• For every non-password authentication you need a client.

Why do you see an ECP as the good trader?

Matthew: what I wouldn't like is the required usage of a password. I give them the certificate and they can enter, using a smart card.

Alternatively you can issue short-lived certificates (RFC3980); in the case of windows it takes a mini driver to make your certificate look like a smart card token so it can be used for authentication. In the background you keep refreshing the certificate once in a while (1 week, 1 month, etc.) and pop up a web browser to a SAML re-authentication that proves you are still affiliated and authorized.

Classical OTP. You write a smart card, keep refreshing. You wrap that with a mini driver. From a tech perspective it will work, but from the administrative side: how will I make them available to people who have no or a minimal IT support.

The first time they log in you put up the regular authentication.

If you need other services like storage it’s reasonable to go for a Moonshot installation.

Project Moonshot-> www.project-moonshot.org

What is the current state of the Moonshot? The reason you don't see a lot of deployment is because only if you do windows to windows, there is a decent chance that Moonshot will work out for you.

The other option would be SPNEGO / Kerberos which would be an unworkable solution for most people due to configuration complexity.

HTTP Mechanisms

keybase.in? Doesn’t do SSH, SAML, OIDC, X.509

New HTTP mechanism would be better than password.

In the case of IoT authN/authZ you can look for IRTP ACE working group

In general the non-web HTTP authentication has not found its way to standardisation 5 years ago and now days all you have left is resort to ugly hacks. Today what you will do is maintaining ugly hacks.

Non-web SSO

Some tools are only available from the command line. When on Linux, solution is relatively easy. Some are only accessible on Windows. This becomes hard.

SAML ECP supported by Shibboleth.

How many use cases are not SSH? There’s is one: RDP

SSH key management could be a solution (80%).

• Not cheap for users.
• Users don’t always understand PKI
• Infrastructure to generate an SSH key
• Local trust is always easier than remote trust.

SPNEGO, FIDO, SAML ECP -> most likely only password based -> means maintaining large password stores in your infrastructure.

Challenge: getting users to accept new software on their machine.

IoT changes the need for non-web, i.e. non-HTTP, authentication.

“Our” needs for standard are relatively small compared to the “rest”. Makes our influence small.

LDAP Provisioning:

1. create user account
2. store given SSH public key