Web SSO support comes to JSCAPE MFT Server in the form of two widely accepted standards: OpenID and SAML. Earlier this month, we already talked about SAML. So now it's time to get acquainted with OpenID.
Unless you're already familiar with Web SSO and the benefits it offers, we recommend you read these two articles before proceeding:
OpenID in a nutshell
OpenID refers to both a standard for Web SSO and a user identifier.
The OpenID Web SSO standard offers an environment wherein users can authenticate with a single entity (known as an OpenID provider or identity provider) in order to gain access to several OpenID-enabled websites/web applications (known as service providers or relying parties). Blogger.com, StackOverflow.com, and Slashdot.org are just a few of the many existing sites that already function as OpenID-enabled service providers.
As indicated earlier, JSCAPE MFT Server (v8.8 and above) domains can also be OpenID service providers.
In an OpenID environment, a user no longer has to go through lengthy registration processes upon arriving at web sites he hasn't registered with before. Instead, he simply enters either a special URL or his OpenID (the identifier) and a much shorter authentication/validation process kicks off.
As of this writing, GMail email addresses can now serve as user OpenIDs. Thus, users can either enter their GMail address on an OpenID field or click the "login with Google" as shown below in order to access OpenID-enabled service providers.
Why use OpenID?
The effectiveness of any Web Single Sign-On technology is highly dependent on the extent of its adoption. The more websites or web applications there are already implementing it, the greater the chance more users will want to use it. Conversely, no one would bother subscribing with a SSO system if only one or two sites support it since its main function (i.e., enabling access to multiple sites) would be very limited.
Luckily for us, OpendID is backed by large companies like Google, Yahoo!, PayPal, BBC, and IBM, many of whom even serve as OpenID identity providers and are actively promoting the use of OpenID. This has helped boost the popularity of the standard.
OpenID normally features a decentralized design that allows all players (user-agents, relying parties, and OpenID providers) to link and interact dynamically. And it does this without requiring complicated configurations, metadata exchanges, specialized browsers, or even browser extensions; operating simply on a "trust and accept all comers" principle. This design makes it very appealing to organizations who want to deploy an OpenID-enabled web application.
Note: Some organizations (like those governed by regulations like HIPAA or PCI-DSS and hence require high levels of privacy and security) may not want to go all-out with the "trust and accept all comers" principle. OpenID can be implemented to suit those organizations' requirements as well. We'll be talking about that particular implementation later in the article.
OpenID already boasts of over a billion registered accounts worldwide. Yes, some of your end users (like those who use GMail and other Google apps) likely already have an OpenID account.
Because of OpenID's huge user base, applications that support OpenID logins can easily gain widespread adoption when they are introduced into an organization. This alone can be a very compelling reason to use OpenID because it can help maximize utilization of IT investments.
Being a SSO standard, OpenID also comes with all the benefits typical SSO technologies provide. To learn more about these benefits, we encourage you to read the articles we recommended earlier.
Let's now take quick look at how OpenID Web SSO works.
How OpenID Web SSO works (common implementation)
Like SAML, OpenID has three main players: an OpenID Provider (OP) a.k.a. Identity Provider, a Relying Party (RP) a.k.a. Service Provider, and an end user.
✔ An OpenID Provider is an entity where the end user authenticates, i.e., where he submits login credentials. The OP creates an assertion that a user is associated with an identifier and submits it to the RP.
✔ A Relying Party is an entity providing some kind of service, e.g. secure file transfers. It is also the entity who receives the assertion created by the OP. A JSCAPE MFT Server deployment using OpenID Web SSO is an example of a RP.
✔ an End User is simply a person who wants to gain access to a RP's services/resources.
The basic flow is as follows:
1. First, the end user arrives at the RP via a Web browser (which, in OpenID jargon, is known as a user-agent) and then inputs his OpenID there. The RP then proceeds to normalize the OpenID that was entered.
Normalization is a process used in obtaining a valid OpenID identifier from the entry. This is necessary because the user may, for example, enter "john.hisopenid.com", "http://john.hisopenid.com", "email@example.com", and so on.
2. Once the OpenID has been normalized, the RP then carries out a discovery process which would enable it to identify the OpenID provider (OP) of the OpenID in question. After identifying the OP, the RP then issues an OpenID Authentication Request and then redirects the user's browser to that OP along with the Authentication Request.
3. Upon receiving the request, the OP determines whether the user has already logged on. If he has not, the OP challenges the user to authenticate.
4. The user submits the required authentication credentials, e.g. username and password.
5. Assuming authentication succeeds, the user is then considered "logged on". The OP then creates an assertion indicating the successful authentication and then redirects the user's browser to the RP along with that assertion.
6. The RP verifies all the information it receives and then, upon finding everything in order, grants the user access.
A more secure implementation of OpenID Web SSO
Steps 1 and 2 demonstrates OpenID's "trust and accept all comers" principle. As you can see, a user can come in with just about any valid OpenID issued by also just about any OpenID provider. That may not be acceptable to organizations with stringent security and privacy requirements.
Here's a more secure implementation. Instead of allowing users to come in from any OpenID provider, OpenID can be implemented in such a way that a specific (and presumably trusted) OpenID provider is first enrolled with the Relying Party. Then only users coming in with an OpenID issued by that particular identity provider can be allowed to login via Web SSO.
The flow of this implementation is the same as the previous one, except that it no longer performs the discovery process in Step 2.
While this implementation is certainly more restrictive than the previous one, it is also much more secure. It is the kind of OpenID implementation you'll find in JSCAPE MFT Server. In our next post, we'll show you how enable the OpenID Web SSO functionality on the latest version of JSCAPE MFT Server.
The latest version of JSCAPE MFT Server now supports OpenID. If you need your end users to share files securely but are finding it difficult to convince them to course their files through your secure file transfer server, this version's OpenID login capability just might be the answer.
As always, this version of JSCAPE MFT Server comes with a FREE fully-functional evaluation edition, so if you just want to give it a try first, feel free to do so.