As a newbie to Yodlee platform, I understand the basic concepts of Aggregation API .
Is there a way to plug in as a bank to supply direct data link instead of screen scraping to supply yodlee plaf and data model to be supplied to devs?
Yes a bank can feed obfuscated data, this is done by placing a middleware server between the core banking and the channel delivery switch.
Companies like Yodlee and Mint, et. al., rely on such a mechanism to provide access to their information partners.
Having said this, I'd be very surprised if any bank would provide you with direct access. Its a pretty cumbersome process even for the most reputed and well-intentioned of companies, individually, I doubt you will get direct access.
Related
I work for an ecommerce site and we are looking to expose much of our core functionality via a set of APIs. We plan on re-writing some of our own public facing applications (e.g. the main shop website and our mobile app) to call these new APIs also. We also want to offer some of these APIs out to third-parties who want to integrate with us.
My first question is - what is a suitable authentication method for these APIs? Everything I read is about OAuth, but am I right in saying that this doesn't fit in this case as we're not looking to use another log in system (e.g. Facebook, Google) but rather restrict access to our own API (so maybe an API key or JWT solution would be better?)
Secondly, our current website has it's own user accounts system. How do you offer /user endpoints (like GET user/1235/paymentmethods) in an API like this? Surely the actual user (website customer) needs to authenticate somehow in order for the given API consumer to access their data.
I've spent the last 2 days reading about this but I'm at a loss as to how to go about this! Any help much appreciated.
I am working on a news media website, and I am looking to add feature to allow users to register, login and make comments.
For example (New York Times login/register screen)
May I know what options are available, what are the common approaches publishers would choose ?
So far I have been looking at:
AWS Cognito: Allows to create own user directory, and authenticate.
Disquss SSO: also implemented commenting.
In house development: Code a new microservice to manage user directory and store/serve comments, alternatively using AWS Lambda. I am very keen to go down that path, example, but this might costs a lot to develop + maintain.
User data security is my top consideration, I would prefer to use a separate system to store user data. Either a robust third party service or complete in house development of a new system.
Any suggestions?
Thank you.
These are web-standards for single sign on:
OpenID
OpenID Connect
Companies like Google and Facebook provide authentication using Google-/Facebook-accounts. As far as I know, Google uses OpenID Connect which is based on OAuth. However, I don't know if you don't have to store user data any more at all when using this.
I believe it's worth checking again if authentication and commenting should be combined, especially when using a third-party-solution. It makes it harder to change one of the two.
This could give you some more ideas: https://en.m.wikipedia.org/wiki/List_of_single_sign-on_implementations.
I'm building a new web application that serves a form requesting the user's card information. Submitting this form will post the form data to a different, fully PCI-DSS compliant application.
Does the application that serves the form to users need to be PCI-DSS compliant also, even if I don't read card information in that application?
As far as my brief googling session has shown, it seems that PCI-DSS compliance is required in any application that "handles" card information. I'm not entirely sure where "handling" that information begins and ends.
PCI/DSS was updated in 2014 (with requirements that became mandatory in Jan 2015) to deal with services mechanisms like that used by stripe in the form of a more stringent self assessment questionnaire (SAQ A-EP V3) which is described as:
New SAQ to address requirements applicable to e-commerce merchants
with a websites that do not themselves receive cardholder data but
which do affect the security of the payment transaction and/or the
integrity of the page that accepts the consumer’s cardholder data.
Content aligns with PCI DSS v3.0 requirements and testing procedures.
This makes it clear that compliancy is required.
Your use case sounds similar to Stripe's, and they say you'd need to use SSL on your page but otherwise can self-attest to compliance.
https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do
You may want to consult an auditor and get a formal opinion from them, though.
We need to accept credit cards (from anywhere in the world) directly on our website. We'd like to use PayPal, but NOT require a PayPal account. The user should be able to simply type in the credit card, date and cvv directly on our site and go. I'm having a hard time figuring out what PayPal API I need to use for this, to integrate with our Java-based server. Turns out PayPal has an overwhelming number of APIs and documentation.
It looks like this link is what I'm looking for... sort of. But can I post this directly from JavaScript? It includes account name and password, which would be in the clear for anyone to see, so I'm thinking this must be server-side code. So the idea is to use a REST API to do this? So the client must pass the credit card information to my server, which then calls PayPal's server?
I'm a little lost, when looking at all the APIs at the Rest API page. Which ones exactly do I need to use?
There is also this link but I'm not familiar with "curl" -- looking for Java. Maybe the distinction is minor and easy to convert from one to the other?
Vern, if you look at the top of this page, you'll see Java (click Java) as one of the languages supported by the PayPal REST Payment API:
https://developer.paypal.com/webapps/developer/docs/api/
You will see related sample requests that use the Java SDK:
https://github.com/paypal/rest-api-sdk-java
in SAML 2.0 you can use the AttributeStatement element to provide any kind of application specific information.
What I was wondering, is it really good design to pass business related information within a SAML assertion? Shouldn't this data be provided in a e.g. separate web services call?
I just want to ask for best practice in this case or any real world experiences.
Regards,
Andreas
It depends a lot on just what information you're conveying. For instance, on the application I work on, we use attributes to indicate what web site features should be shown to the user being logged on. That's clearly an appropriate use. Now, we also allow use of attributes to create a user profile, even though we have a web service that does the same thing (and in fact, the implementation calls the web service behind the scenes). It's not an ideal context for that sort of thing; there's no endpoint to convey the web service response to, or any errors resulting from the attempt. But we get a fair amount of resistance from customers, who don't want to have to call a separate web service before they can make an SSO call. So we've had to compromise. What we've done is require that if a customer wants to use this particular functionality, that they provide an endpoint (either email address or web page) to receive errors from the web service call. And if they're concerned about security of the information being conveyed, they can use standard XML encryption.