Original Source - How to Register An OpenID Connect Client

These days, most websites and mobile apps don’t know how to authenticate you. Instead, they call the APIs of services offered by popular “Identity Providers” or “IDPs”, like Google and Facebook.

This enables a person’s “user” information to be utilized at many different websites on the Internet, and information about a person can be shared with websites and apps on an “as needed” basis. Of course web site developers don’t want to learn a different authentication API for each IDP. And many organizations don’t trust a third party to authenticate its people. So the Internet has moved to standards. The most widely used standard for Web authentication is SAML. Perhaps the most promising standard for authentication is OpenID Connect, which is a profile of OAuth2.

The explosion of Two-Factor Authentication technology…

One of the most important new technologies that is driving infrastructure changes is the explosion of strong factor authentication technology. There is a triangle of authentication consisting of price, usability and security. Not all triangles are equal. New technologies are arising that are more convenient, more secure and less expensive than passwords.

Once a company makes an investment in strong authentication, they want to use that authentication technology across the maximum number of apps. For this reason, it makes sense to support open standards, so all applications can benefit from the availability of these new organizational authentication capabilities.

The Problem of Client Management

It’s not only people that need to be authenticated and authorized. There is a proliferation of agents that act on behalf of the person, or are independent entities. How are these authenticated and authorized by the organization… ?

Sesimic Shift: LDAP or WAM?

I think the seismic shift is from WAM (web access management) –> Federation, not from LDAP –> Federation. LDAP is still entrenched as a robust persistence infrastructure for user claims and password credentials. The problem with WAM products (i.e. Siteminder, OAM, TAM…) is that the cost has been high, customers are locked in (why else did CA buy Netgrity…), and integrations have been slow.

Companies realize that whether they are integrating authentication with internal apps, external apps, or off-the-shelf products, open federation standards enable consolidation, which saves money, and improves security. In the large companies I’ve worked with, the security department did not have control over the applications, so even though they were “internal”, a top-down approach was inefficient. It’s better to publish your standards, and let the internal app developers “help themselves” than to push a WAM architecture on them. In this sense, the fact that there are external apps just provides further evidence to a trend that had already clearly emerged.

IAM, not IDM

Often times, clients and consultants put too much emphasis on IDM, and not enough emphasis on organizational trust management. It’s not just that I need to provision my users for external websites, but I need to understand with which websites I have shared which attributes. Also, organizations need to trust users who authenticated outside the organization. Most large organizations participate in an ecosystem of autonomous parties, and publish websites that are used by many outside the organization. This is the old problem of extranet user management. Trust management, IMHO, is one of the biggest challenges…

Where does XACML fit?

If you talk to organizations, you’ll find that the is no clear trend for XACML’s adoption. Proprietary and custom solutions are the rule in authorization right now, with most authorization actually taking place in the app. To what extent centralized authorization will be achieved is totally uncertain, and I would argue that this is the “adjacent possible,” as described in Stephen Johnson’s book “Where Good Ideas Come From” — you can’t have authorization before we have clear standards for authentication. In terms of adoption of technology, I’m bullish about UMA, and in fact I think UMA and XACML are complimentary… app developers want JSON/REST… and it would be more suitable for the PDP to form a XACML request to a XACML PDP, then for the app developer to learn XACML. In any case, I’m a fan of XACML as a standard for expressing authorization rules, but I do think that the technology is better suited for server side developers.

Who will Outsource IDaaS?

I disagree with the common assumption that the majority of “IDaaS” will be outsourced. Perhaps for SMB market, this might be true. But many large organizations maintain core TCP/IP services, and AAA has traditionally been managed within the organizational perimeter. In fact, many organizations simply cannot outsource this function for security reasons. With standards, we will drive down the costs of the software and the resources, and AAA will be simply another linux or windows service that can be configured.

Article Resource:-http://gluu.jimdo.com/gluu-blog/what-exactly-is-identity-federation/

Gluu is currently evaluating the idea of incorporating the Asimba SAML platform on the Gluu Server (in addition to Shibboleth). SAML can be confusing, even to the experts. We at Gluu worked on the diagram below as a simple overview of why a SAML proxy might be useful, and where it would fit in the Gluu open source stack.

A few things to note:

The main advantage of the proxy is a very simple configuration for the SP. If the website is a SaaS or off-the-shelf software, you may only get one way to trust the IDP. Discovery and re-direction to your respective home domain IDP are handled by the proxy.

Internal websites that don’t care about other federated IDPs can just point to your SAML IDP directly.

Applications using the Asimba proxy can request a specific authentication type via SAML ACR request.

Authentication business logic is handled in OX–no need to support 2FA in both SAML and OAuth2.

In many cases, the OX OP also grabs a legacy SSO ticket (i.e. CAS, Siteminder, etc.)

In a federation with many IDPs, if the participants trust the federation operator, it is efficient for the federation operator to manage trust with the websites. For example, instead of updating 1,000 IDPs to update their configuration, just update the proxy.

Article Resource:- http://thegluuserver.wordpress.com/2013/12/30/use-case-for-asimba-as-saml-proxy

Sprint should support the OpenID Connect protocol for authentication. Sprint has a lot of customers. Telco’s are in a superlative position to authenticate people using mobile devices.

However, how can websites use the sprint.com domain to authenticate people?

I suggest Sprint aligns with the OpenID Connect standard. Further I propose that Sprint use the open source OX platform to do this.

Google open sources the client API to authenticate people, but it doesn’t publish the server code it uses. The Gluu project provides the best implementation of the new OpenID Connect protocol.

Sprint should align with the same authentication protocol as Google, Facebook, Yahoo and Microsoft, and other consumer IDPs. There is no point in writing your own code to implement OpenID Connect when you can use open source software. And by supporting open source, you can help the ecosystem.

Frankly you have no interest in your partners doing a bad job of authentication. Its a win win… Gluu is a small company. We are struggling to fund this open source software and maintain our lead. I think there are several ways we could help Sprint, and you can help Gluu, and that you can help make the Internet a safer place by opening up your platform for third party authentication.

Q & A — The specifics of your Opportunity:

Who are your competitors?

Our competitors include Ping Identity, ForgeRock, CA SiteMinder, IBM Tivoli Access Manager, RSA ClearTrust, Oracle Access Manager, OneLogin, Okta, StormPath

What differentiates your solution from your competitors?

There is only one other open source platfrom: ForgeRock. That platform was designed in the early 2000s. It is not easy, and it doesn’t support the new OAuth2 profiles (OpenID Connect / UMA) that are needed by mobile developers.

What would be the benefit of using this solution?

Sprint could support standard API’s for authentication and authorization, and enable an ecosystem of partners to authenticate Sprint customers via Internet standard API.

How is this better than Sprint’s current solution?

Supporting standards is important because we live in a world where there are multiple consumer IDPs, and if a website needs a special API to use your IDP, it will probably just not support you.

What is the cost of your solution?

Gluu sells support on its product. However, I think there might be some sponsored co-development opportunities.

Who are some of your current customers?

Toshiba uses Gluu to deliver authentication for its Cloud TV Service in Japan and Europe (and soon in the US). We have more than 20 university customers, in addition to a number of large enterprise customers. We also are designing an authentication/authorization platform for the State of TX K-12 students, and a citizen authentication platform for the Philippines (90M users). In the telecom industry, we worked with British Telecom on a multi-year VOIP project, and have advised Rackspace on the design of their authentication system.

Do you have any additional information or comments?

Please check the latest OpenID Connect test results. Look in the last column for Gluu, and you can see that our server is currently the most comprehensive implementation of an OpenID Connect Provider.

Article Resource: http://thegluuserver.wordpress.com/2013/11/22/submission-to-sprint-innovate-why-sprint-should-support-openid-connect/