0

User details (name, address, etc) are stored across multiple sites that are vendor specific. For example, vendor A holds information concerning room bookings while vendor B holds information specific to cabs, vendor C holds information regarding parking, and the list continues. They also hold credentials specific to each of those services so there isn't a shared credential system or the concept of an identity provider. The information across these systems may hold the same information e.g. name, address, etc

Each of these vendors publish an API or web service of sorts. Since there is now a requirement to aggregate these services however provide users a single journey (as opposed to redirecting them to a vendor specific site), what options are available to authenticate users across all systems.

Bear in mind we have no control over vendor specific web services nor in some instances is there interest from the vendor to change their API to support an identity provider system.

Improve this question

1 Answer 1

Reset to default
1

You'll have to authenticate to a single system that, in turn handles the connections to the other services. Then the user should see a single 'logon' user and a single website. The back-end then has to deal with retrieving data and aggregating it for display.

The service will have to have knowledge of all the other service's authentication mechanisms, possibly storing and associating each 3rd party service login info with the single user login you now manage (a bit like how some banks will provide you with an aggregated service from your other financial provider's services by asking you for your password and storing it). However, if the 3rd parties only require a login for authorisation to access their service, you can now have a single user that belongs to your new aggregation service. This depends if the information you receive is tailored to a specific user registration.

Improve this answer
3
  • So what you are suggesting is storing user credentials for other services in our system? That introduces multiple issues. 1) We would need to seek authorization to store the credentials for an external service. 2)We would need a mechanism whereby we have no knowledge of their credentials. 3)If there is a breach, we could be held liable 4)If the user changes the password with the other party, there would be no immediate replication
    – Motivated
    Feb 27, 2015 at 8:00
  • 2
    If the 3rd party services have their own user auth system that requires individual logins then yes, that's the only way, there's no magic that lets you replace their auth system. If you can have a single user for your service and obtain the same data then that is obviously better. You didn't tell us enough details to say more.
    – gbjbaanb
    Feb 27, 2015 at 8:29
  • @Motivated, you might want to have a look at how zapier and ifttt handle this concern with how they interop between different APIs. The trick is making it as seemless as possible for the end user, and tripple checking your security policies. If you are lucky, you can prefer OpenID style systems and not need to store credentials in the first place.
    – Ape-inago
    Mar 29, 2015 at 22:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.