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.

Navigation

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

Advertisements

4 Responses to “Co-Branding , White Labelling”

  1. Jana Reddy Says:

    Another perspective to SSO is to have multiple services with single ticket. The cleanest and most promising way to provide a integrated services in my view is to very clearly separate the business services from delivery services. I personally like the approch of a separated UI and Business layer to achieve this rather than a single SSO product, because I think SSO works great when you are building the systems new and with SSO planned, but most of the times we are faced with a situation where we are working with spectrum of products that are sometimes a old as 20 years but work great.

    The concept of separated presentation and business layer so much around us, be it changing mobile phone covers to having MVC design pattern.

    In the business layer service providers expose pure business methods, these could be Web Services, Remote EJBs, Messaging Queues, cgi, hardware gateways or any thing that can speak to remote system. In the delivery layer the focus is to give a consistent look-feel and same context to the users, so that at various times users do not feel that they are being shifted from one place to another to accomplish something.

    This concept is visible in Banks for example, in some banks we recieve a service token then use that token to present the cheque (Queens English speaking) in one counter then go to another counter for receiving the money, this is SSO in my view. Second approach is siting at one counter and have the clerk run around to processes the cheque and hand you over the money, this is integrated delivery.

    In computer systems behind the scene the authentication and access control to the business layer can be exercised in multiple ways, based on the maturity of the business layer. If it the business layer for example is like FEDEX then we will have tracking information to track the consignment or if you have a FEDEX account you would use a fixed FEDEX account number and tracking number in combination to fetch the data. In the second case FEDEX account number remains constant and tracking number changes with transaction.

    In the presentation layer we have various services like Portals, XSL transformations, Screen scrapping technologies or even simple web interfaces to consolidate the services and present. This will ensure that presentation layer has full control on UI, can work with different types of authentication and data services of backend.

  2. Pranshu Jain Says:

    You have brought out a very important point Jana. So in the perspective of a Third party software it must honor the token given by the host system.
    The system architecture must provide this pluggability. Something for SaaS vendors to take note of.


  3. Hi,
    Thanks for the great explanation on White Labels and White Labelling.

  4. Calvin Says:

    Hello, its pleasant piece of writing concerning media
    print, we all understand media is a great source of data.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: