WIXLIB

Why single sign-on is so expensive and what you can do to reduce costsmodules, development of cross-platformintegrations may be more expensive.The rise of standards-basedcommunication between systems(XML and JSON data objects) hasbegun to minimise or eliminatecomplexities arising from cross-platformcommunication, since most web servicestend to use platform-independent datastandards. If your CMS or AMS is builton an older platform, or if the webservices API of either system is not welldeveloped, you will still encounter thesecross-platform issues.For the purposes of your SSO effort,this means that your development teamneeds to have capabilities in the platformsand programming languages involvedfor each system that will be part of theintegration. For example, if your AMSis the .NET-based NetForum and yourCMS is the PHP-based Drupal, then yourSSO team needs to have experience with.Net, PHP, NetForum and Drupal. If yourinternal team or your primary vendordoes not have this breadth of experience,then you will need to find a vendor withresources that complement those of yourexisting team.Ideally, at least some members of yourresulting team should have experienceacross both systems, as this minimises therisk of communication problems betweentwo teams with different expertise. If thatis not possible, you can also try to buildand mediate a collaboration betweentwo separate teams with complementaryexpertise. Members of the team shouldhave the skills necessary to accomplishtwo important tasks: (1) communicatethe login credentials between each of theinvolved systems, and (2) customise eachsystem to store and reflect the logged-instate, in both the database and the userinterface.If you’re in a position to select thesystems you plan to integrate throughSSO, your implementation will be simpler4Journal of Web Management and MarketingOprica JWMM V1-1-1.indd 4if the systems use the same platform and/or programming language.THE ADDED COMPLICATION OFAPPLICATION PROGRAMMINGINTERFACESBeyond the platform and language thatit is built on, each software applicationhas a unique architecture, and theapplication programming interface (API)that interacts with this architecture isdifferent. An API is a collection of queriesand functions that makes it possible fordevelopers to retrieve information, initiatea process, verify the results of a request,and otherwise interact with a system.Each API is different, so what can bedone in one system might not be possiblein another, making communicationbetween systems challenging. So, evenif your developers know a platformand a programming language, they canstill be limited by the depth of theirunderstanding of the APIs involved inyour SSO integration.Also, while some are more robustthan others, APIs are limited and maynot contain the necessary features toperform particular tasks. Most of the time,developers are limited to what the APIprovides: they cannot create their ownqueries from scratch. This means that inorder to achieve a particular business need,if your needs are not supported by theAPI out of the box, then developers mightneed to come up with a creative, customsolution. This can be expensive, as it mayrequire developing and testing severalsolutions.If you’re in a position to select thesystems you plan to integrate throughSSO, your implementation will be lessexpensive if each of the systems has arobust web services API available fordevelopers. To execute a basic SSO, theAPI for your software products must beable, at a minimum, to do the following:Vol. 1, 1 1–12 Henry Stewart Publications 2050-0076 (2017)22/03/17 10:26 am

Moore, Oprica and Gallerizzo Retrieve an existing user, based oneither username or ID, Create a new user, based on name,email and password, Log a user in and out programmatically(without the user making a physicalclick), and Keep track of the user’s authenticatedstate, as they move between pages.the work at both the project level and theindividual task level. Wherever necessarymake sure to step in, mediate and facilitatea collaborative approach between themultiple participants and create anenvironment where they can succeedtogether rather than becoming adversarial.The vendor for each of your systemsshould provide all available APIdocumentation, including a list andexplanation of all the methods, dataobjects and service endpoints availableto developers. This is especially criticalfor your AMS and CRM software. Theinformation must be available earlyin the development cycle, to allowdevelopers to properly plan and architectthe SSO solution.Similarly, you will want to ensurethat your team has deep knowledge ofthe APIs involved in your integrationand appropriate support for when theyencounter knowledge gaps or unexpectedobstacles. If your team doesn’t have expertknowledge in each of the products youare trying to integrate—which is commonand likely—then you will need to finda vendor whose skills complement yourteam’s. Otherwise, you may encountersignificant problems trying to get the twosystems to work together.You’ll need experts on both systemswho have experience implementingSSO, and who are willing to worktogether. If you have multiple teams orvendors involved in your efforts, thereis a significant risk that each team willdefine its responsibilities more narrowlythan you’d expect. As a result, there willlikely be a ‘grey area’ of functionalityin the middle that each team assumesthe other one will take care of but inthe end neither one will. To avoid thissituation ensure that the team leads clarifyexpectations and assign responsibility forThe architecture for your solution willbe developed based on the desired userexperience and implementation method,combined with the specific features andlimitations of the APIs involved in yourintegration. The other important factoris deciding which system should be yourlogin authority.In general, the login authority shouldbe whichever system is best suited tohandle user and member records, as wellas sales and transaction history. Most often,this is your AMS or CRM. In contrast,an application like a CMS would be lesssuitable, since it is focused on contentdelivery and not on your audience. Ifyour AMS or CRM is at the centre ofyour SSO solution, it will be easier tocommunicate information about membersand transactions between each systemin the integration, and you will spendless time developing workarounds andcustomisations to accomplish these tasks.With this in mind, map out all of thesystems that need to be integrated. Selectwhich system should host the login andaccount creation screens, in what order thesystems should authenticate, and whereusers should be returned after a successfullogin. Similarly, describe the logoutsequence, and where users should bereturned after logout. Determine sessionduration and the methods for maintaininga session between each system, anddescribe error handling for each system ifauthentication fails.Describing all of these things in detailcreates a shared understanding of the SSO Henry Stewart Publications 2050-0076 (2017)Oprica JWMM V1-1-1.indd 5Vol. 1, 1 1–12ARCHITECTING A SOLUTIONJournal of Web Management and Marketing522/03/17 10:26 am

Why single sign-on is so expensive and what you can do to reduce costsdevelopment plan for your team, andforms the basis of documentation for yourimplementation.Your development teamwill advise on additional points to cover inthe architecture, based on your requirements.‘SIMPLE’ SSO AND MORE COMPLEXINTEGRATIONSThe complexity of your SSO project will, ofcourse, influence the cost. In a simple SSOimplementation, two applications, such asan AMS and a CMS, need to have a sharedauthentication channel.That is, when a userclicks the login button in either one of theapplications and submits their username andpassword, they will automatically be loggedinto both applications. At this point, the usercan perform tasks with both applications,since they are authenticated into each.The issues that we have discussed so farare the main challenges with a simple SSOimplementation.SSO implementations can becomemore complex in many ways, andsometimes multiple factors are involved.Most of the time, your business goalswill extend beyond ‘simple’ SSO in atleast one of the following ways.You maybe integrating more than two systems,using different login or logout methodsfor specific systems, integrating dataand services between the systems, orusing non-standard session lengths orauthentication rules.More than two systemsWith each additional system that youintegrate, the SSO implementationbecomes more complex, because theidiosyncrasies of each system and itsAPI compound upon the others. Also,with more than two systems involved,most likely your development team willincorporate experts from multiple vendors.With this larger team comes a greater needfor clear and open communications. It alsocomplicates scheduling, as it becomes more6Journal of Web Management and MarketingOprica JWMM V1-1-1.indd 6important to synchronise work efforts.The integration components for eachapplication should develop in parallel, sothat issues are discovered and mitigatedearly in the project for each vendor.Otherwise, when issues arise, one team maybe too deeply committed to their solution,which can impact the broader integration.As your business grows and changes,you may find that you need to addmore systems to an existing SSOimplementation, or you may need tochange one of the systems. If the newsystem is substantially different from whatwas previously integrated, this can requiresignificant adjustments and revisions tothe existing solution. Sometimes thedevelopers of the original solution areno longer available to answer questions,which can introduce perplexing problems,and can mean that the entire integrationneeds to be reworked. For this reason,we encourage clients to documentthe methods and processes used in anSSO implementation, along with issuesencountered and their resolutions, forreference in future development efforts.Different login or logout methodsFor most businesses, one goal of SSO isto unify the login and logout screens. Inimplementations with several systemsinvolved, it’s possible for one of thesystems to be significantly limited orout-of-step with the others. Most often,this happens when a new application isadded to the integration after the initialSSO implementation; and it’s morelikely to happen if the team workingon the new integration does not havecomplete documentation on the existingimplementation, and early access to thebroader SSO team.If one of your systems requires aseparate login screen from the main SSOlogin shared by other systems, then thereshould be special planning to addressthis in the architecture, so that you canVol. 1, 1 1–12 Henry Stewart Publications 2050-0076 (2017)22/03/17 10:26 am

Moore, Oprica and Gallerizzoavoid a disjointed login experience—where users are logged into somesystems but not in others. The planningwill involve new triggers in the broadersystem to synchronise all the entry andexit points so that clicking login orlogout from any screen in the systemworks the same way.Data and services integrationCompanies often implement SSO as partof achieving a bigger goal, such as unifyingan interface for registration or sales orpersonalising the user interface. Makingthis happen requires more robust systemsand APIs than simple SSO, as well as agreater understanding of the APIs andthe systems involved. Common examplesof data and services integrations includeusing your CMS to mimic AMS andCRM functionality, such as: Registering, joining or renewing Managing an account profile orpassword Creating a shopping cart Payment processing Displaying purchase historySimilarly, businesses often want to leveragedata stored within an AMS or CRMto customise the website experience,personalise content delivery or determineroles or access to content. Examples of suchdata include all profile fields and customerdata beyond the customer ID, such as: Name, address or profession Membership or registration type andstatus Sales funnel flags Purchase history Group or list identifiersIf the AMS or CRM provides a front-endinterface for your visitors, then usingthese interfaces will minimise yourcosts. Otherwise, you will be re-creating Henry Stewart Publications 2050-0076 (2017)Oprica JWMM V1-1-1.indd 7Vol. 1, 1 1–12interfaces that already exist, and that aredesigned to work seamlessly with theapplication. Using these interfaces maynot be practical if they are difficult touse, inaccessible, hard to customise orotherwise lack features and functionalitythat you want to offer.If you want your visitors to use onesystem to accomplish tasks that aredriven by another system, you need adata and services integration. In such animplementation, SSO is the starting pointfor your project, but it will not accomplishyour goal. Development will need tocontinue to retrieve and communicate thenecessary data, and further, to update thedata stored in each system as a result ofvarious transactions.That is, in this situation, you’re notprocessing just a login but individualtransactions as well. When someone makesa purchase, the authority system has tobe notified, has to log and validate thepurchase, and has to return the results ofthose operations. It may also need to sendalong information that the user needs tosee and the companion system needs inorder to continue providing appropriateinformation, such as compoundingdiscounts, showing related purchasesor preventing certain items from beingpurchased according to business rules.A data and services integration isattractive because it keeps your websitevisitor within the same ecosystem:the visitor does not have to movebetween two or more different systemsto accomplish their goals. It increasesdevelopment costs astronomically sincethe website system has to act as a one-stopshop, mimicking—indeed, almostreplicating—the features and functionalityof another system.In effect, each of these additionaltransactions beyond login requires thesame attention to detail as the primarylogin transaction. This compounds the setsof data that have to be communicated andJournal of Web Management and Marketing722/03/17 10:26 am

Why single sign-on is so expensive and what you can do to reduce costsstored within each systems, and it likewiseincreases the burden of keeping thisinformation in sync between each system.When setting a budget and definingrequirements for an integration, makesure you decide whether the integrationshould only involve SSO, or whetherit should also involve data and servicesintegration. As described earlier, the dataand services integration may be muchmore expensive. Each additional layer ofdata and services increases the cost. TheROI may be justified, but be aware of howyour business needs will impact the cost.Non-standard sessionor authentication rulesWith security in mind, many applicationsare designed to reflect standards forsession duration and authentication. Forexample, most applications will log a userout after 20 minutes of inactivity, andmost will prevent simultaneous loginsfor a single user. If your business needsrequire something different, particularlyif your requirements are not availableout-of-the-box for all of the applicationsinvolved in your SSO integration, thenyour developers will need to find acreative solution to the problem thatworks for all of the involved applications.It’s important to identify and discussyour requirements for session duration,simultaneous sessions, ‘remember me’functionality and similar issues early in theprocess, so that your development teamcan identify whether customisations arerequired for any of the systems involved.COMPLEX IMPLEMENTATION:AN EXAMPLE OF THE ISSUESIn a recent SSO project that we workedon at Fig Leaf, our client wanted to ensurethat purchases within the AMS wouldbe reflected in the user profile in theCMS without requiring a login, so thatcontent access restrictions handled by the8Journal of Web Management and MarketingOprica JWMM V1-1-1.indd 8CMS would update at the same time—effectively allowing the visitor to accessthe content that they had just purchased.Importantly, the client desired for thisprocess to happen without requiring thevisitor to logout and login again. At thispoint, you’ll recognise that this is a dataand services integration, built with an SSOimplementation.This request makes a lot of sense froma user experience perspective.When anyof us makes an online purchase throughAmazon, for example, we expect that thispurchase will appear in our purchase historyimmediately; and if we have purchasedonline content, we expect for it to bedelivered to us as a result of our purchase.In most situations where we experiencethis process as visitors, we are usuallyvisiting e-commerce websites, where thecontent presentation and the purchasing areexecuted on the same software.In contrast, the client making thisrequest is a membership association, andthe purpose of their website is twofold:sell and renew memberships and delivercontent. They rely on two separatesoftware applications to meet these needs.To accomplish sales, they used their AMS.To accomplish content delivery, theyused their CMS, which offers a morepowerful publishing interface that includespersonalised marketing and role-basedcontent delivery. Using a single applicationfor both purposes was not an option forour client. So, these two systems needed tobe integrated to reach the client’s goals.Since the client had been using theAMS for substantially longer than theCMS, and there were several otherbusiness processes hooked into it, thesoftware had been customised overthe years. Knowledge about thesecustomisations was dispersed over severalteams of consultants and internal teammembers, some of whom were no longeravailable, and documentation was sparse.As a result of this, it was important thatVol. 1, 1 1–12 Henry Stewart Publications 2050-0076 (2017)22/03/17 10:26 am

Moore, Oprica and Gallerizzothe AMS remain the interface for bothauthentication and purchasing, as well asthe authority for all member data. So, weworked with the current team of AMSconsultants to ensure that after each updateto a member record—whether initiated byan online transaction or a manual recordupdate—the AMS would ping the CMSto retrieve the updated member record.Initially, although the CMS receivedthe ping to retrieve the record, recordswere not being updated. After a diagnosticworking session with the AMS team,we discovered that the ping to us wasbeing delivered too soon in their internalbusiness logic. By postponing the ping, thisissue was resolved.Then we discovered a bigger problem:with the ping to update, we could retrievethe member record and all of the releva

content management systems such as Ektron, Episerver and Sitefinity, and has delivered highly customised website functionality and features to many clients over the years. He is also well-versed in third-party data integrations involving AMS and CRM systems, such as NetForum, Membersuite and Microsoft Dynamics.