Velruse is a set of authentication routines that provide a unified way to have a website user authenticate to a variety of different identity providers and/or a variety of different authentication schemes.

It is similar in some ways to RPXnow with the exception of being open-source, locally installable, and easily pluggable for custom identity providers and authentication schemes.

You can run Velruse as a stand-alone service for use with your websites regardless of the language they're written in. While Velruse itself is written in Python, since it can interact with your website purely via HTTP POST's.

Velruse can:

• Normalize identity information from varying provider sources (OpenID, Google, Facebook, etc.) to Portable Contacts.
• Simplify complex authentication protocols by providing a simple consistent API.
• Provide extension points for other authentication systems, write your own auth provider to handle CAS, LDAP, and use it with ease.
• Integrate with most web applications regardless of the language used to write the website.

---

Overview

Velruse aims to simplify authenticating a user. It provides auth providers that handle authenticating to a variety of identity providers with multiple authentication schemes (LDAP, SAML, etc.).

Eventually, Velruse will include widgets similar to RPXNow that allow one to customize a login/registration widget so that a website user can select a preferred identity provider to use to sign-in.

In the mean-time, effort is focused on increasing the available auth providers for the commonly used authentication schemes and identity providers (Facebook, Google, OpenID, etc).

Unlike other authentication libraries for use with web applications, a website using Velruse for authentication does not have to be written in any particular language.

API

Velruse implements an API similar to RPXNow to standardize the way a web application handles user authentication.

Velruse Authentication flow

1. Website sends a POST to the auth provider‘s URL with an endpoint that the user should be redirected back to when authentication is complete and includes any additional parameters that the auth provider requires.
2. When the auth provider finishes the authentication, the user is redirected back to the endpoint specified with a POST, which includes a unique token.
3. Website then makes a query to the UserStore using the token that was provided. The user’s identity information will be returned, or an error if the authentication was unsuccessful.

If the website is unable to directly access the UserStore then Step 3 can be replaced by issuing a HTTP POST in the background to the auth provider requesting the user’s information with the token.