I am using Container-based services, is there a way I can find out the container requires MFA or not after i have additemforcontentservice1?
Cheers,
Patrick
You will have to call getContentServiceInfo1 API before calling additemForContentService1 to know if the content service(the bank) requires MFA or not.
You need to look for the field "mfaType". This field will only be present for MFA sites with "typeName" as "TOKEN" or "IMAGE" or "SECURITY_QUESTION".
Also please follow the API flow Add_Account and Refresh_Account
for building the container based add account process.
Related
You get the problem reading the title. Is there anyway I can sign up customers using commercejs. The documentation is only showing login/logout methods but not sign up.Is there anyway I can do it through commercjs. Or should I use other authentication service like Firebase Auth??
There is no specific way to register a user as Commercejs does not store any kind of password.
The only way for registering a user is to use https://commercejs.com/docs/api/#create-customer as per API reference docs. however if you want to integrate some kind of custom auth you should definitely use this reference:
https://commercejs.com/docs/api/#issue-jwt-for-customer
This allows you to issue a JSON web token for a customer directly using your secret Chec API key. This may be a desirable option if you are integrating your own customer authentication, and simply need a token to authorize API requests as your customer with.
I have personally used this method along with Firebase auth.
I/we at www.dr.dk are working on a Sonos integration with the bare minimum functionality. This means that we wish to apply anonymous access in this first version of our Sonos integration.
In the API documentation
https://musicpartners.sonos.com/node/289#toc0
is says 'Finally, you can decide not to use any authentication, also knows as anonymous access. ...'
Which we read as an option to not to implement authentication endpoints like 'GetAppLink(...)' etc.
So now we have teste our service and it appears to work fine, as far as we know. Therefore we have now started to fill out the application registration form.
In the registration form we find the following required fields regarding authentication as depicted in the image below
Screenshot from the application registration form
As we see it these fields are related to authentication and seems somewhat confusing to us. So with our logic - anonymous authentication means that no test accounts or customer care accounts are needed etc.
So the question is. What are we missing ?
You can just mark those as N/A for each of the fields.
Suppose that I have a web application. Consider it like a Black-Box for now. I want to use a backend system to limit what a user can view/do on the app.
i.e. Sample users can only do three functions, Premium users can do 10 functions and see more pictures.
What is the best way to do it?
I'm trying to using WSO2 Identity Server, but it doesn't offer this functionality. So I've thought that maybe I can integrate it with the WSO2 API Manager and make an API that limits users' access to a certain resource. But really I cannot find if it's possible do it. Anyone know it?
Please refer to : https://docs.wso2.com/display/IS530/Access+Control+Concepts
1) WSO2IS can act as a coarse grained access manager. Your application will act as a fine grained access mnager.
It means that roles can be defined in WSO2IS, managed and assigned to user. From there Roles assigned to one user can be provided as clains with the identity token generated by WSO2IS and sent to the application.
The application, on the other side, will manage roles to permissions links.
Access control is then done at each request by the application, based on the roles presented in the Identity Token by the user and the Permissions grid based on roles in the application.
2) The access control at the application is a business logic you must implement (or at least configure if it a COTS). It is possible to outsource this logic to WSO2IS as policies on attribute (with Workflows).
Please look at : https://docs.wso2.com/display/IS530/XACML+Architecture
Jeff
I've implemented an application using Moqui Framework. I provided url:http://localhost:8080/fvl-plus-runtime/rest/s1/example/examples
It is getting error like:
User [null] is not authorized for View on AT_REST_PATH [/example/loginexamples/{username}]
You can add ArtifactAuthz records for all users, like the ones already in place for admin users for the REST APIs. In general it is best to secure all API access, and that is how things are setup by default. There are various examples you can follow to see them in action, see the extensive comments in the rest.xml file (the XML Screen for the /rest path).
This feature as been added in commit #44272ba. You are now able to create a new REST service and set require-authentication=anonymous-view or anonymous-all.
See How to create a publicly accessible REST API in Moqui for more details.
I'm trying to test the MFA in Yodlee with the dummy account DagBankTokenFMPA. I let the MFA timed out and now everytime, I try to refresh I got the same error :
{"siteRefreshStatus":{"siteRefreshStatusId":10,"siteRefreshStatus":"SITE_CANNOT_BE_REFRESHED"},"siteRefreshMode":{"refreshModeId":1,"refreshMode":"MFA"},"updateInitTime":0,"nextUpdate":2047149073,"code":522,"suggestedFlowReason":{"suggestedFlowReasonId":2,"suggestedFlowReason":"ACCOUNT_IN_ERROR"},"suggestedFlow":{"suggestedFlowId":3,"suggestedFlow":"EDIT"},"itemRefreshInfo":[{"memItemId":10088102,"itemSuggestedFlow":{"suggestedFlowId":3,"suggestedFlow":"EDIT"},"itemSuggestedFlowReason":{"suggestedFlowReasonId":2,"suggestedFlowReason":"ACCOUNT_IN_ERROR"},"errorCode":522,"retryCount":1}],"noOfRetry":1,"isMFAInputRequired":true}
How can I prevent that ? Do I need to stop the refresh with stopRefresh and start over ?
In this case you need to call updateSiteAccountCredentials API and just pass the details again, this will trigger a refresh and then you need to call getMFAResponseForSite to see what MFA information is required by the bank.
To add more, it seems like you are mixing two sets of APIs here. We recommend to either use container based APIs or Site Based set of APIs, in conjunction with Core APIs which are common to both.