Tag Archives: active directory and single sign on and

Gluu releases first version of Open ID connect (OX)

Gluu announced the release of open ID connect (OX) version 0.0, an implementation of the XDI 1.0 standard under review by the OASIS XDI Technical Committee. This initial release provides a core Java API for XDI, a graphical browser for displaying XDI graphs, and an XDI server which provides XDI persistence, operations, and messaging. OX leverages XRI 3.0, a separate OASIS proposed standard for persistent and re-assignable naming objects on the Internet.

“The imminent completion of the XDI 1.0 standard represents the culmination of years of hard work by the OASIS XDI Technical Committee. All of us at Gluu are grateful for the opportunity to bring this vision to life in code,” said Michael Schwartz, Founder / CEO of Gluu. “Today, privacy on the Internet is broken. The architects of the Internet did not design the network to address the complex security and privacy requirements that are needed by our society. OpenID connect single sign on and XDI technology is a deep structural solution to empower people and organizations to both share and protect data that is essential for their digital existence,” he continued.

About Gluu:

Gluu publishes free open source Internet security software that universities, government agencies and companies can use to enable Web and mobile applications to securely identify a person, and manage what information they are allowed to access. Using a Gluu Server, organizations can centralize their authentication and authorization service and leverage standards such as OpenID Connect, UMA, and SAML 2.0 to enable Single sign on server (SSO) and trust elevation.


Using OX for Social Login

So you have a website or mobile application, and you want to support social login? Consider using the following imaginary website for Acme Incorporated. Instead of your local username and password, you decide to use the “Login with Yahoo” button.

OX enables a domain to define custom authentication scripts. When you click the “Login with Yahoo” button, the login page uses Acme’s OpenID Connect API (served by OX), and includes the GET parameters “auth_mode=yahoo”. This enable OX to select the correct authentication script for Yahoo. This script could use the Yahoo API to validate your current session or to re-direct you for authentication.

Once you are authenticated, you can see a portal with several panels. Each panel is served by a different back-end web server which needs to know your identity in order to display the right content.

Its a bad idea to instruct each backend web application to use the social API directly. If you did that, each application would have to implement business logic for every social login API. If Yahoo or Google updates their API, every application would have to update their code. Plus, introducing new authentication mechanisms would be difficult: you’d have to get every app to do so.

Using the social login API directly could make it hard for the backend web applications to get all the needed information about you. For example, the billing application might need your Acme account number, which Yahoo does not know.

But how does Acme know which person corresponds to which social account? This is where you need to consider enrollment. Frequently, a person with a local account specifies that they want to associate a social account. Or if you first authenticate with a social login, you may need to provide additional information–for example address, phone number, account number–to enable the organization to setup a local account.

In many ways using a social login API is no different from the considerations of using any external authentication provider, for example Duo or OneID. A custom authentication script could even support uber-authentication API’s, like Janrain or Gigya. These services would enable you to create one custom authentication script to support multiple consumer IDP’s.

The key takeaway from this should be the following: within your domain, stick to open standards like OpenID Connect and SAML. This gives you the most flexibility to change your business logic for authentication, without having to update your applications.

Gluu vs. Ping Identity – a (mostly) unbiased comparison

We know that the strength of open standards is that customers will be able to choose from many commercial and open source solutions. We believe more gas stations on the corner means more business for everyone.

We “enjoy” competing with Ping, if that’s possible. Ping provides greatly needed support for open standards, and has literally hosted the ecosystem of companies in their hometown and abroad at many great events. Not surprisingly, we frequently get asked the question: How does Gluu compare to Ping? In the interest of efficiency, we decided to write this blog to help explain what are some of the reasons why some customers might prefer Gluu… or Ping.

If you fit into one of these categories, you may prefer to go with Gluu Green:

You want Open Source. Either you are paranoid, and you actually want to read all the code. Or you have realized that open source is simply the best development model for writing servers based on open Internet standards.

You want OpenID Connect or UMA today. Compare the current results of Ping and Gluu from the latest OpenID Connect Interop (#5). Its going to take Ping a long time to write all that code. And there are even more endpoints and tokens for UMA.

Gluu offers tools for Multi-Party federations. This type of federation is used extensively in higher education and government. It provides both the tools and rules to enable networks of autonomous IDPs and RPs to drive down the cost of SSO, improve security and protect privacy.

You want a managed service. Gluu’s use of Puppet to standardize delivery of the OX stack offers a compromise between a multi-tenant SaaS identity offering (PingOne), and an enterprise software deployment (PingFederate). It offers the operational advantage of a SaaS service, without the security and privacy dis-advantage of storing PII on shared servers.

You don’t want to pay per user or per application. The Gluu Server subscription offers a predictable annual operational cost. There are no per-user or per connection fees even for strong multi-factor