Centralized Authentication - building a Jasig CAS server  

Helping Rid the Web of Passwords

It’s getting close to that time of year when we take time to go home and visit family and loved ones at the end of another year.
And, when you’re a “computer expert” like me, that means one thing:

Trying to sort out the disaster your family has made of their passwords and web-accounts this year.

Simply ask any baby-boomer what the worst part of the internet is? Answer: “too many passwords”

And they’re absolutely right. It’s not just a baby-boomer problem –
it’s a problem for all the users that we work so hard to build online services for.

The Authentication Problem #

Passwords are painful for users and a common failure point for websites, but they are required.

The web is a public place and like any public place, it will be graffitied.
In order to protect our users’ content we need to authenticate them, traditionally with passwords.

The trouble with passwords is that there is a 10% chance your password is in this list:

— Skyhigh Networks - You Won’t Believe The 20 Most Popular Cloud Service Passwords

And passwords like that mean that it’s possible for the services we build to be broken into far too easily.
Every site which contains useful data for it’s users has this issue – and it gets worse.
What do you do when you have multiple sites that provide services to a related user base?
This is exactly the problem that many of our clients find themselves with.

How can we help?

We can’t make passwords go away, but what we can do is provide a way to share user data across several sites.
This, at least, can allows us to have 1 password for each user and have 1 place for them to login and then share that authentication information across any of the related sites and services that we provide online.
Then it’s a little bit easier to encourage our users to use better passwords to protect their data.
In addition, we can provide a centralized place for them to manage, update and maintain their profile.

You’re probably already familiar with this if you employ any cloud services. Typically larger service providers like Google, Apple, Microsoft and Yahoo! allow you to login to one service, like Mail, then allow you access other services, such as Photo's, because you already logged in to read your Mail.

This is called: Centralized Authentication

Centralized Authentication — (CAS) #

Recently I put my head down and built a CAS server.

The Central Authentication Service (CAS)
is a single sign-on protocol
for the web.

Why would we do this? The answer is simple: to save our users from remembering more passwords.
By using this CAS service we will be able to provide a user the ability to login once and access a large variety of sites and services without having to login again. For instance, they might be able to:

1. go to their Drupal site and update content for an upcoming blog,
2. manage a Mail Campaign for upcoming notification to their members,
3. access an intranet portal where they can see all their internal documentation and accounting information
4. finally they may want to track the analytics to see what all of their members are doing across all of their sites, in one central place

If this sounds awesome, it is.
Check out https://wicket.io to learn more about this modern approach to core data management for your organization.

What Does It Mean #

1. Our client presents with an existing user/password database used for their site.
2. They want to move away from this silo and take advantage of more contemporary distributed services, while still allowing their users authenticated to their site.
3. Need to transition to multiple loosely-coupled sites sharing authentication credentials.

What is CAS? #

Single Sign-On (SSO) is a mechanism for related websites to securely share authentication information.
If more websites took advantage of SSO, then we all would have fewer passwords to remember.

And of course, this can extend further using broader [and older] backing protocols to provide authentication, such as:

• LDAP – simply logging into your office computer
• or, OpenID – logging into your cloud-based email

OpenID is an open standard […] that allows users to be authenticated by certain co-operating sites […].
In other words, users can log into multiple unrelated websites without having to register with their information over and over again;

— https://en.wikipedia.org/wiki/OpenID

The Way it Works #

The first time a user attempts to access a web page protected by WebAuth, they will be sent to a central login server (weblogin.stanford.edu at Stanford) and prompted to authenticate. Normally, they will be asked for a username and password, although other authentication methods are possible. Once the user has logged in, the weblogin server will send their encrypted identity back to the original web page they were trying to access. Their identity will also be stored in a cookie set by the weblogin server and they will not need to authenticate again until their credentials expire, even if they visit multiple protected web sites.

— http://webauth.stanford.edu/

BCrypt for Encryption #

For our CAS implementation we had to extend the protocol to interact with exisiting user/password stores already using bcrypt.
Is bcrypt a good choice? - it’s better than many alternatives.
There is no perfect encryption algorithm, given time and computation these codes can be cracked.
But there is a concept of sufficient security.
No matter which side of the debate you land on, bcrypt is a still solid choice:

• http://codahale.com/how-to-safely-store-a-password/
• http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
• https://news.ycombinator.com/item?id=3724560
• http://www.daemonology.net/blog/2009-05-09-scrypt-key-derivation.html

CAS implementation using BCrypt #

Link to gist or working java code.

• https://github.com/Jasig/cas-overlay-template
• https://github.com/Jasig/cas/blob/v4.1.2/cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext.xml#L105-L112
• bcrypt

WEB-INF/deployerConfigContext.xml

    <!-- Authentication handler component for wicket credentials. -->

    <bean id="bCryptAuthenticationHandler"
        class="io.wicket.cas.BCryptSearchModeSearchDatabaseAuthenticationHandler"
        p:dataSource-ref="dataSource"
        p:tableUsers="${database.bcrypt.table}"
        p:fieldUser="${database.bcrypt.field.user}"
        p:fieldPassword="${database.bcrypt.field.bcrypt}"
    />

    <bean id="dataSource"
        class="com.mchange.v2.c3p0.ComboPooledDataSource"
        p:driverClass="${database.driverClass}"
        p:jdbcUrl="${database.url}"
        p:user="${database.user}"
        p:password="${database.password}"
        p:initialPoolSize="${database.pool.minSize}"
        p:minPoolSize="${database.pool.minSize}"
        p:maxPoolSize="${database.pool.maxSize}"
        p:maxIdleTimeExcessConnections="${database.pool.maxIdleTime}"
        p:checkoutTimeout="${database.pool.maxWait}"
        p:acquireIncrement="${database.pool.acquireIncrement}"
        p:acquireRetryAttempts="${database.pool.acquireRetryAttempts}"
        p:acquireRetryDelay="${database.pool.acquireRetryDelay}"
        p:idleConnectionTestPeriod="${database.pool.idleConnectionTestPeriod}"
        p:preferredTestQuery="${database.pool.connectionHealthQuery}"
    />