Gluu has both a social and a business mission. These missions need not be at odds. In fact they are symbiotic.  The business vision of Gluu is quite simple: offer a utility service to help organizations control access to valuable online resources. Our social mission is to make the Internet a safer place for people and businesses by writing great open source software.

When I started Gluu in 2009, I felt access management tools were too expensive for many organizations. There are millions of domains on the Internet.web access management system software like Siteminder had a small impact because only the Fortune 500 could afford it. Open source software was piece of the solution. The other piece was to provide a cost effective mechanism to enable organizations to support the open source software, so they could build and operate a mission critical IT service.

Utilities provide the economies of scale to drive down the cost of technology, making it available to a wider audience. At the dawn of the electric era, only the largest companies could afford electricity. They built power plants on rivers. It wasn’t until the advent of electric utilities that drove down the price of electricity that small businesses and ordinary people could use it. Big businesses also benefited–they no longer had to build and maintain their own power plants. 

Gluu’s utility access management service funds our social mission. To make the Internet a safer place, we need to make security software more available to developers and system administrators. The infrastructure we are building today will provide a coral reef on which a diverse ecosystem of new Internet services can thrive.

Networks have an ebb and flow of centralization and decentralization. At first, a technology is introduced by an innovative company. For-profit companies inevitably are quicker to invent products to address market needs. Over time, standards emerge, and the networks decentralize. We saw it with Compuserve and Email, AOL and the Web. With better identity standards, Google and Facebook may get their comeuppance. In the 90’s, it would have been crazy to imagine every organization launching their own AOL. And yet, that is exactly what the Web made possible. And the result of this was a network richer and more diverse than any media executive at AOL ever imagined. Furthermore, the Web was hacked to achieve purposes never envisioned by AOL executives.

Internet identity is at a similar stage as the Web in 1995. Right now we use services like Dropbox, Google and other centralized services to share files and data. sso service rely on us having accounts in the central node. I can only share a doc on Google with you if you have a Google account. Or worse… services rely on security by obscurity (which is not really security at all). With standards and open source software, each domain could build their own data federation services like Google, or perhaps new services that no Google engineer has even imagined.

This trans-formative vision for a decentralized and safer Internet motivates our team at Gluu. And hopefully we’ll also make some money. If we can do a little of both, or a lot of both, we’ll be satisfied that struggle was worth it.

10-20 years ago there were no open standards for identity and access management. It was not even clear that “identity” would use HTTPS for transport.

I speak with system administrators, security architects, and web application developers who are describing how day by day it is becoming more difficult for them to manage inbound SSO from partners, and outbound SSO to an array of internal websites, SaaS services and Federated Sso.

Without Internet standards to authenticate a person at a domain, bridge identity solutions have emerged, for example Facebook Connect and Google sign in. At the same time, enterprises are locked-in to bridge solutions like “CA SiteMinder” or “Oracle Access Manager” — high priced, proprietary “identity provider saml and Access Management” suites.

20 years after the Internet explodes, open standards for Identity and Access Management have finally evolved. And there are a few open source implementations of these standards.

Like TCP/IP or the Web, standards for identity can be the coral reef for an ecosystem of enhanced services. Just to give one example, think about document sharing. Google has jumped out in front… but it only works if you a have a Google ID. Without Internet standards to build on, document sharing applications will have to use identity from centralized hubs.

As a society, Internet standards for identity can reduce our reliance on big centralized identity kingdoms like Google, Facebook, and Verizon, who have proven to be easy targets for government spying.

Internet standards for identity will also help us battle some of the smaller identity fiefdoms: for example the websites and applications who do a bad job storing our passwords. This will make the electronic world safer for the average person.

In the next 1-2 years, every domain on the Internet will adopt Internet standards for authentication. Will these organizations use (a) a cloud providers like Microsoft or SalesForce? (b) enterprise software from a company like Oracle? or (c) Open Source? The last option will have to overcome a serious handicap without a book from O’Reilly, telling them that its possible.

How the various platforms interact is complex. Although silo’d guides exist to document these platforms, its hard to figure out how to get the components to work together to deliver a robust authentication and entitlements management service for your domain.

This book is late… it should have been written in the ’90s, but the problem of “Internet identity” was inconveniently large and complex. It requires both “tools” and “rules” to make it happen, and neither were clear when the Internet was under-aged.

The book would have the following sections: (1) OAuth2 (2) SAML (3) LDAP. The sections could contain sub-chapters on available open source platforms. For example Shibboleth, SimpleSAMLphp, and Asimba for SAML. OX, NRI, or MitreID for OpenID Connect, and OpenDJ and OpenLDAP for LDAP.

I was recently asked by a customer “What configuration changes, if any, need to be made for the resource providers to accept both the old local database authentication, and the new federated SAML or OpenID Connect authentication?”

Remember, a person may navigate to an RP directly, or have an RP bookmarked. You can’t count on the person navigating via the gateway portal.

At a high level, the RP will need to update their application to support more than one workflow for authentication. This involves establishing a procedure for “Discovery” to bootstrap identifying a person who is currently an anonymous Internet request. The discovery process will determine whether to prompt the person for their existing username and password, or to re-direct the person’s browser to a trusted IDP for authentication.

How the RP handles discovery, is up to them. Here are a few examples of how different websites accomplish this:

1) Guide the person to select the appropriate IDP. A good example of this is the Educause Login Page

2) Use DNS hostnames to provide the discovery “hint” to the websites. A good example of this is salesforce.com
They issue each partner IDP a dns sub-domain, for example “gluu.salesforce.com”
When their web servers sees the inbound hostname, it can select the appropriate IDP and protocol for authentication.

3) Prompt the person to enter either an identifier or some kind of hint, for example an email address or an organization’s name. The app can then set a permanent cookie to record the person’s discovery selection and automatically route subsequent requests

4) OpenID Connect Discovery
Ask the Person for an email address, use the specified hostname to send an HTTP GET Request ala Webfinger, now OpenID Connect Disovery:

GET /.well-known/openid-configuration HTTP/1.1
Host: seed.gluu.org

You can see a sample Response from Gluu’s test OpenID server:
http://seed.gluu.org/.well-known/openid-configuration

This response tells the RP where to register to get an API key and secret (where meaning what URL), where to re-direct a person to be authenticated, and where is the USER_INFO endpoint, where the RP can request user claims (i.e. email address, phone number, first name, etc.).

5) SAML Discovery
For more info, see the DiscoJuice open source product.

Enrollment
Questions about enrollment are common. Consider the workflow for enrollment post-authentication. What is the best way to reconcile existing accounts with your federated accounts?

Do you allow users to use their existing usernames and passwords?
Do you force users to create a new username and password in a registration process?
How you we reconcile these accounts with existing accounts at resource providers? Some users may already have work on a resource provider they wantto be able to access.
 
Each app needs to be considered on a case-by-case basis. Each RP with legacy local database accounts needs to define an enrollment process for new people who show up via federated identity, and for existing users who are upgrading to federated identity. Whether the RP wants the person to create a local username, or to use another user claim (like the email address) to identify the person, is up to them. Post-enrollment, the RP should not accept the old password. In fact, old passwords should be obliterated, and of course no new passwords should be collected. The RP may want to check if a person’s information is updated at the backend IDP. On eachauthentication, the RP can request the latest user claims (i.e. email address, phone number, etc.) and update its local database if necessary.

Article resource:-http://thegluuserver.wordpress.com/2014/01/20/discovery-aka-wayf-for-local-saml-and-oauth2-authentication/