Co-Branding , White Labelling
September 5, 2006
Popular brands want to offer more and more services – revenue generating or otherwise. Service providers are more than happy to oblige. Such arrangement requires the service provider to co-brand or completely brand ( white label) the application.
The services have content pages and application pages, both of which have similar ( but slightly different) requirements, and usually end up having different solutions.
Lets look at the common requirements and technology options for the same. The requirements will be:
Access: Single Sign on or common user view.
Customized URL – even for secure pages.
Branding: of applications and content pages.
Custom contact phone numbers etc – filtering into error pages.
Brands Ad engine for ad-supported pages.
Brand’s site stat
Today, I will cover what I know about Access.
Access to a co-branded site.
Single sign on is a commodity. Users expect single sign on. Users expect to see a single view of their profile as long as they think they are using the same brand’s application. The requirements typically include one of the following authentication methods
- Same LDAP / ADS / directory: Most intranet applications would require suppliers service to hook into their organization’s directory. This will require relevant network access as well.
- Authentication Token: This is the most common way to implement SSO today. The Brand will call providers’ SSO service to get a token. The token is added to URL the user uses to access the service and the service, by looking at the token knows that it should consider the user as logged on. Another variation of this is by using an Authentication token which is algorithm based ( like that of SecureId) which avoids the initial web service call. I have seen other variations like encryption of some parameter like userId and if the application can decrypt it, it considers the user authenticated. However there is nothing preventing the user from bookmarking it and hence compromising security.
- Domain Cookie: If the service provider is using the same domain as the brand, the signon can be done via a domain cookie. The primary server ( belonging to the brand) does a signon and places a domain cookie on the client browser. The client browser returns this cookies to all machines within that domain. For example a cookie placed by www.yahoo.comwill be returned to mail.yahoo.com as well if its a domain cookie. The cookie contains all authentication information ( usually encrypted). I have seen and used Blowfish algorithm for encryption in these cases.
- Specialist SSO tools and Service: Use of specialist SSO tools and services is ever increasing. Gone is the era where only the very rich could afford a SSO system. Now we have a host of these, CAS, JOSSO, cosign, webauth and possibly lots more, though I see most enthusiasm towards CAS. Increasingly, organizations are hosting services based on either these products or otherwise to let all web applications authenticate against it.
- Client scripts: some systems rely on client scripts to make the browsers sign in. I am increasingly seeing fewer evidences of the same.
- Portals: service provider may need to provide portlets for the portal server of choice of their client.
Common user view
While it makes sense to keep the passwords all in one place, it is more than likely that all applications will need a user profile of their own – to manage authorization and other application specific user preferences. So the different applications will have users in their own database. However there are some elements of user profile which are common across applications ( like name). Increasingly, we see the “my profile” page being hosted as a service, visible to all applications to use.
What does it mean for service providers:
They have to support more than one way of single sign on. Application design should allow for adding more methods of sign on as needed.
There will be more than one ways of user profile access. The service providers should implement it however should design the application to get specific fields from the user profile service.
It should be possible to write portlets to sign on to this application. The vendors should consider providing JSR 170 compliant portlets.
In the next post I will try to write on other aspects mentioned earlier.
Continue to Customized URL