IBM WebSphere Portal Server, since Version 7, allows users to log into websites built on the WebSphere Portal platform using social credentials that they have created on public social networks such as Facebook, LinkedIn, and Twitter. Authentication and authorization protocols such as OpenID, OAuth and SAML enable this capability and provide advantages to both the end user and the organization. This section provides a brief overview of these protocols and describes the advantages (and potential pitfalls) of using social credentials for authentication and authorization on a social portal. The section concludes with references to instructions for setting up social login capabilities on the IBM WebSphere Portal platform.
Social authentication and authorization protocols
There are several industry standard protocols that allow for federated identity management. Federated identity management allows users to authenticate into and/or allow access to their private resources on a site without that site storing their credentials, or even providing the user with a login mechanism hosted on the site. Instead, the site will allow access to the user if they are authenticated by an identity management system that the target site trusts.
OpenID is an open industry standard sponsored by Facebook, Microsoft, Google, and Yahoo (among others) that allows a user to be authenticated on a site using third-party authentication services called identity providers.
OAuth is also an open industry standard but differs from OpenID in that it is used for authorization not authentication. With OAuth, the user owns the resource that the target site (OAuth Consumer) would like to access from the site hosting the resource (OAuth Provider). The user has to authorize the OAuth Consumer in order for access to be granted the user's resource.
Security Assertion Markup Language (SAML)
SAML is an XML based standard, driven by the OASIS Security Services Technical Committee, that facilitates the exchange of authentication and authorization information between parties. A user (Principal) who wishes to validate their identity on a website that doesn't store their credentials (Service Provider) does so by providing their credentials managed by an another system (Identity Provider). This requires that the Identity Provider and the Service Provider trust each other and that authentication and authorization information passed between them is agreed upon and securely transported.
Advantages of using social credentials for a website
There are a number of benefits for both the user and the organization when social credentials are utilized on a website for authentication and authorization purposes.
The advantages for the end user:
- Less credentials to manage and remember.
- No need to complete another website registration process.
- Allowing access by the website to resources hosted on other sites that could add increased and more targeted functionality (when using OAuth).
Benefits for the organization include:
- No need to develop and maintain user authentication and user credential management capabilities (reset password, account lockout after failed login attempts, etc).
- Easy access to important social objects such as user status updates and profiles (when using OAuth).
- The organization is not accountable for the secure hosting of the user credentials.
- Infrastructure and space to store user credentials is not required.
Disadvantages of using social credentials for a website
No approach is without some disadvantages. Allowing a user to use social credentials to access an organizations website is no exception.
Disadvantages for the end user:
- Having to create an account on a third party website (if the user doesn't already have one) can be an effort and confusing.
- The end user might not feel comfortable sharing (or creating) a user account with a third party website and would therefore be unable to access the site if no other options are available.
Disadvantages for the organization:
- Dependency on a third party system - If the authentication/authorization system is unavailable for any reason, so is the organizations website.
- Logic will be required on the organizations website if the end user will be allowed to use more than one authentication/authorization provider.
Taking these disadvantages into account, the organization must weight up the benefits against the disadvantages when deciding whether to allow a user to use social credentials on their website. It might well be that that having support for social and organization credentials is the best option.
Using social credentials to allow access to a website built on IBM WebSphere Portal server
IBM WebSphere Portal server allows a user the means to use their social credentials to access web content and applications built on that platform. After deciding whether this approach is beneficial to the organization, there are a number of steps that must be followed to use this capability.
This capability was not available as part of a standard portal installation until Version 8.0. The link below provides details on downloading, installing, and configuring this social credential login capability on WebSphere Portal Version 7:
How to Configure and Use OpenID, Facebook integration on WebSphere Portal
Detailed instructions for Configuring this capability on WebSphere Portal Version 8.0.0.x is provided below:
Integrating with OpenID authentication