Last week we talked about the single sign-on work flow, and Four51’s take on it – Auto Profile Logon (APL). Headphones said that there was way too much information to convey in one sitting, so here he is with a follow-up…
Ah, yes. Way too much to convey in one sitting – so here we are sitting again. Thinking about ways to get users from one system into another system.
Last week, I had mentioned that you don’t even need APL to accomplish this, you can use our logon page and pass a few parameters, just click here.
Would log me in as my user, and the optional productid parameter would take me to a specific product. There is also the optional catid parameter that can be used to land the user in a specific category.
There are two big downsides to this approach, and two reasons why you may want to use the APL functionality instead:
1) Security. While all methods use HTTPS for secure transmission over the Internet, someone with a knowledge of web programming could theoretically use a debugging tool to figure out what their username/password is. This can be an issue if you don’t want people using the site at home or giving the username/password out, or if you’re using a shared password – which many single sign-ons use.
2) User creation. The APL functionality requires a template user so that in the event of a username being passed in the request that doesn’t already exist in CommerceTools, a new user is created. This is especially useful if your users all need the same permissions and products assigned – you don’t need to create and profile any of these users ahead of time.
Once you’ve decided that your customer needs/wants to use the APL functionality there are a few steps:
- Create the APL configuration on CommerceTools and get a template URL that you can give to your customer
- Your customer will need to review the APL documentation, and write some relatively simple code on their intranet that takes the current user logged on their system, plugs the username/email/first name/last name/etc. information into the APL template URL provided, and then redirect the user to this freshly generated URL.
- If your customer doesn’t care about A) above, they can use the standard APL functionality. If they do need that extra level of security, they’ll want to use the encrypted APL functionality which takes a little longer to set up, and can be confusing to troubleshoot.
- Go live (it’s not quite this simple, but it’s not too bad)
A lot of people get hung up on why a shared password is so common and how to sync user data, and the same answer applies to both. You use a shared password so that you don’t have to sync user information between the two systems. The username, first name, last name, and email address on your customer’s system isn’t likely to change. They likely have a policy where passwords need to be changed every so often or users can change their passwords, and there’s no easy way to update that. Also, some customers don’t necessarily want Four51 to have those passwords (although we do salt, hash, and encrypt them so it isn’t really a security risk). Syncing user data would either have to be a manual process, or done with the Commerce Tools Admin Web Services suite. In most cases, it isn’t needed and it certainly adds a layer of complexity.
Well, that’s single sign-on and APL in a two-part nutshell. We have some great documentation about this functionality on the knowledge base, and if you have any other questions please feel free to submit a case or leave a comment here!