admin Posted by:

(0 comments)

Lori MacVittie has a great post over Devcentral at F5 about the current state of Identity for Cloud. It is well worth a read.

I agree completely with Lori's post, especially this quote:

From a technical perspective what’s necessary is a better method of integration that puts IT back in control of identity and, ultimately, access to corporate resources wherever they may be.

It is the wherever they may be part in relation to your authentication server that I have been pondering. Lori suggests using identity bridging to connect SaaS services to corporate identity management services. This is essentially the setup when you add WiKID two-factor authentication to Google Apps for your Domain. The user logs into a corporate identity server (the WiKID server) and the WiKID server vouches for the user via Google's SAML interface. (We do not perform SSO functions, though.)

So let's say you are a corporation moving "entirely to cloud services". In this instance, let's say Google Apps is the only SaaS service you need for now. You're worried that all your corporate data is out there on the Googles. You've decided that Google is better at managing uptime and security, but the lack of control is irksome. (Kind of like the move from IPSec to SSL-VPNs.)

So, you have decided to add two-factor authentication to your SaaS services. Where do you put your authentication server? In the cloud? At home? I think the biggest determinant is what resources do you have at home. In particular, do you have any resources that rely on RADIUS for authentication, such as a VPN? Unlike SAML, RADIUS is not encrypted. Of course, you can tunnel it, but that would increase the complexity of the setup. If you are running your authentication through Active Directory using the Microsoft RADIUS plugin NPS, do you want that traffic coming from the Internet?

So, for me, I would tend to keep the keys to kingdom at home. What about you?