This is the first in a series of blog posts on the nuts and bolts of identity management.
Like most areas of IT, Identity and Access Management has its own terminology, acronyms and jargon. Lots of terms are specific to standards such as SAML and others are more generic and apply to the entire domain of digital identity. Here’s some of the important terms and concepts to understand:
Identity Provider (IdP):This is a technology service (for example, OneLogin) that can “assert” a user’s identity to another resource. An IdP is responsible for authenticating users. Read more »
We have recently released a new feature that also enables OneLogin to be a SAML Service Provider. Most of our customers are used to viewing OneLogin as a SAML Identity Provider where OneLogin authenticates the user and then signs them into other applications using SAML.
For those whose SAML skills are a little rusty, here is an ultra quick refresher. In SAML land there are two parties; the identity provider and the service provider. The identity provider establishes the identity of the user and then signs them into an application, which is also called the service provider. Read more »
OneLogin has just released a Python version of its increasing popular open-source SAML toolkit, which now brings the number of languages supported to a total of five: C#, Java, PHP, Python and Ruby.
The toolkit is very straightforward to use and can be embedded in your application in matter of hours. In addition to being completely free, the toolkit approach has another significant advantage over licensing a commercial, stand-alone SAML gateway. By embedding the SAML toolkit in your code, it will automatically inherit your own application’s high-availability and scalability characteristics and you don’t have to worry about dealing with a separate application or server. Read more »
We have just released SAML toolkits for Ruby on Rails and PHP and we will release more in the coming months. The toolkits are free, open source and you can use them with any identity provider you choose, not just OneLogin.
So why are we doing this? SAML is ideal for web-based single sign-on for a number of reasons. It’s a standard, it’s very secure and and it is very flexible. Unfortunately, as is often the case, flexibility is a double-edged sword and has prevented SAML from being adopted by smaller players because if its relatively high learning curve.
In the cloud, most of the flexibility of SAML is not really needed. If you look at how Google Apps and Salesforce.com have implemented SAML, it is very straightforward and with a product like OneLogin, you can configure these services for SAML in a matter of minutes. These are two of the most widely deployed cloud applications and we think those implementations are reflective of what most other vendors would want to offer to their customers.
Therefore, we have put together basic SAML toolkits that give you the same functionality as with Google Apps and Salesforce. The toolkits support both identity provider initiated and service provider initiated single sign-on. We have already walked through the toolkits with several vendors. One CRM vendor got it working with their application in less than an hour – while we were watching on the video conference.
If you are interested in SAML-enabling your own cloud application, take a look at the documentation for the Rails toolkit or contact us at email@example.com. The code is also available on GitHub at: