how to impalement automated test of SMSOTP on WSO2 platform - automated-tests

I need to test some features on WSO2 Identity Server (IS) in automatic way. specifically the MFA implementation using SMSOTP. This case study refers to implementing an automated test of log in using SMSOTP like the second authentication factor. To do this, we need to obtain the code to be sent via SMS to validate it without receiving it on a cell phone :). Until now WSO2 Identity Server (IS) provides admin API to validate and resend the validation SMS code, but those API do not show the code on the response, this is necessary to can automate the test.
(https://is.docs.wso2.com/en/latest/develop/enable-verification-for-updated-mobile-number, https://docs.wso2.com/display/IS511/apidocs/self-registration/).
One solution is use to the WSO2 Identity Server (IS) SMS OTP Authenticator.
(https://github.com/wso2-extensions/identity-outbound-auth-sms-otp)
this extension exposes an endpoint to validate the SMS code, but I am not sure that endpoint shows the validation code.
I need a way to can obtain that validation code (not in cell phone) to can validate flow from a test script.

First of all, in the identity-outbound-auth-sms-otp repository, there is common module in the /component/common path, you can integrate it to generate SMS-OTPs and validate SMS-OTPs. If you want to retrieve the OTP code you need to use the below toml configurations.
[[event_handler]]
name= "smsOtp"
properties.enabled=true
properties.tokenLength=6
properties.triggerNotification=false
properties.alphanumericToken=true
# OTP validation failure reason will be sent in the response.
properties.showValidationFailureReason=false
properties.tokenValidityPeriod=120
# Same valid OTP will be resent, if issued within the interval.
# Set '0' to always send a new OTP.
# Should be less than the 'tokenValidityPeriod' value.
properties.tokenRenewalInterval=60
# Throttle OTP generation requests from the same user Id.
# Set '0' for no throttling.
properties.resendThrottleInterval=30
You can have a brief idea by following this blog post.

I believe it is imperative to not to send the OTP codes in the API call responses since it is a secret known by the Identity Server and shared only with the user's mobile. So I believe if you want to specifically automate MFA using SMS OTP, you have to go in the correct workflow and do the proper validation. If you specifically consider the SMS OTP flow, you have to validate,
if your SMS sender is working fine
if the OTP validation flow is working fine in the Identity Server
There are different tools you can use to automate SMS workflows, such as mailinator. You can get a mobile number from such a service and use the APIs available with that service to retrieve the SMS received to the user to implement the automated test.

Related

Sign-in with Google without Google Sign-In JavaScript Platform Library for web

I want to add "Sign-in with Google" as an alternative to creating an account when signing up for our services.
I want the process to retrieve the user's email address and name. That's it.
And this example was all I needed
https://developers.google.com/identity/sign-in/web
Worked great. Very similar to Log in with Facebook, which I added last week.
But now I read that it won't be supported after March 2023.
Using the destined-for-the-dustbin JS code, I can get back useful info about the account I'm logging in with.
ID: 10855600*******690837;Frank;Hart;frank.hart*****#gmail.com
The parameter passed to the callback function has a getBasicProfile() method which does the job
var profile = googleUser.getBasicProfile();
But using the new code, I found (by trial and error) that the parameter passed to the callback function is an object, which has three fields, the only potentially useful one called credential, with content such as:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjQ2Mjk0OTE3NGYxZWVkZjRmOWY5NDM0ODc3YmU0ODNiMzI0MTQwZjUiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJuYmYiOjE2Mjg4NTQzOTcsImF1ZCI6IjY1MjE0Nzk1NjY0My05aWVmdHN2bmZraDVma2x1NHUxOGg1Ymc3MDA0YjdsOC5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjEwODU1NjAwNDY3OTg0NzY5MDgzNyIsImVtYWlsIjoiZnJhbmsuaGFydDA0N0BnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoiNjUyMTQ3OTU2NjQzLTlpZWZ0c3ZuZmtoNWZrbHU0dTE4aDViZzcwMDRiN2w4LmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwibmFtZSI6IkZyYW5rIEhhcnQiLCJwaWN0dXJlIjoiaHR0
Now, my guess is that I have to send that string to my server, and do something with it, possibly involving the "Client secret" that is associated with the App on developers.google.com. But I've been looking most of the day, and I'm not sure if what I've found is necessary - I hope it isn't
https://developers.google.com/identity/sign-in/web/backend-auth
Do I now need to become an OAuth2 programmer just to add a Sign-in with Google button?
The good news is that you do not need to learn OAuth2, you do not need to follow the backend-auth guide linked in your question. This migration actually removes the complexity OAuth2, access and refresh tokens from sign-in. Yes, there is the difficulty of learning and understanding the new and different way of securely sharing the user profile. Hopefully, after cresting over the learning curve you'll see how this makes working with a profile more simple.
JSON Web Tokens (JWTs) are now used to securely share the Google Account profile.
That big pile of text--the credential, it is a base-64 encoded and a JWT.
jwt.io has an online JWT decoder that's handy for testing and a nice writeup of working with JWTs. After decode its just a JSON object, no get methods are necessary, just access the individual fields.
All this said, you need to decide whether decode should take place in the user's browser, or on your backend server. This depends upon how you're working with the profile and your setup. Typically, you'd decode on your server after a redirect using data-login_uri in HTML or login_uri in JS.
There are a large number of JWT decode libraries available, so it's very likely you'll be able to add a JWT library, decode it and you're all set to access the individual fields in the credential.

Why isn't there a Voided date property in DocuSignEnvelopeInformation object?

I am using DocuSign REST API 3.0 to integrate with my app.
After a DocuSign envelope is voided, if I invoke EnvelopesApi.ListStatusChangesAsync for the envelope, I get back an EnvelopesInformation object, which shows both a VoidedDateTime and a VoidedReason property. This is exactly what I need to update my database but all the documentation tells me I should implement
a webhook to receive status updates instead of invoking the API, so I implemented the webhook.
However, when DocuSign invokes my webhook after I void an envelope, I get an DocuSignEnvelopeInformation object from DocuSign, which does not appear to have a VoidedDateTime or Voided property. There is a VoidedReason property, and there are properties for other status dates, such as Created and Sent. Why no Voided property?
What this means is that after the webhook is invoked (and updates my database with incomplete information), I still have to invoke the API to get the VoidedDateTime into my database. Did I just waste my time implementing the webhook? Or am I missing something?
You should explicitly select Envelope Voided Reason checkbox in your Custom Connect configuration. Once this property is selected then you will be able to know the reason why this envelope was Voided.
Webhook is a notification system, where it will notify your System with some data/metadata about the envelope, and if that data does not seem sufficient for your requirement then you need to use API to pull the rest of the data. If Webhook is not available then you need to do a Polling mechanism using some scheduler to keep polling DocuSign after certain interval which does not seem to be a good design and not very scalable. So Webhook design helps your system to know when to call DocuSign platform.
Please note, it seems you are using SOAP API, but I would recommend to implement a new API integration with DocuSign's Rest API as it will have latest features which might be missing from SOAP API.

What needs to be done for an action submission?

I am developing a google smart home action.On the Google Home App, I can set up my test action. I can use the Google Home mini turn on my devices. I used a C++ server as fulfillment (url: https://xxxx.xxx.com/google/smarthome). My server can receive and process SYNC, QUERY and EXECUTE methods.
When I running the SMARTHOME-WASHER demo. It used firebase and homegraph. I can see the washer status data in firebase database. I can see the functions in firebase, such as fakeauth, faketoken, reportstate, requestsync and smarthome. Evenytime when I turn on/off the washer. I saw reportstate and other requests.
But when I test my test action, in my test action's firebase, there are nothing. No status data, no request data.
When I use Test suite for smart home, the WASHER-DEMO is OK, my test action failed to get device list from HomeGraph.
So I want to know:
1. If firebase is necessary when I used my own fulfillment ?
2. How to report state? Request from google server to my server, or conversely?
3. When I add my test action on Google Home App, the firebase database is empty. Is this a issue?
4. What need I to do , if I want to submission my action.
I have been troubled for more than two months. Thanks for your help.
Firebase is not required. You can use any backend implementation you want. To simplify development, our codelab uses one type of implementation. If you want to use another host and database, then you can change how you handle the requests.
Report State is a command you send from your server to the Home Graph. It's proactive, meant to be sent when a device's state changes.
If you are not using Firebase for your test action, then you would not see any Firebase activity. This is fine.
To submit, you should follow this guide. Primarily, run the Test Suite and then submit your action through the Actions Console.

I want to know how the botbuilder listen,and where it listen?

We have created Robot on hipchat and yammer with hubot, and they worked very well.
Recently, our team want to create a bot using hubot on Microsoft Teams, but met some problems.
I read the guide document and find that we should first allow external apps in Microsoft Teams .We should ask our Microsoft Admin team to help to open this on. Now, we are review this with our security team about this.
There is something I want to get from you:
1.I find if I want to active the hubot, I should first set an endpoint, what is this used for? Why should we set this?
When we enterprise hubot with hipchat and yammer, we just need an account, set the user name and password, tell hubot the group
Name we want hubot join, and it worked like a normal user.
2.I found “#robot.router.post #endpoint, #connector.listen()” in the code,
So, how the botbuilder listen,and where it listen?
3.Are messages all transport by http? Is it safe enough?
I just went through setting up our Hubot in teams as we will be moving from Hipchat and thought I could answer some of these questions.
The endpoint is used to send messages to your bot since it does not join as a user like Hipchat. When run with the botframework adapter /api/messages is used for communicating with your bot by Microsoft.
I'm not certain where in the code it listens but you have to # mention the bot in order for the app in teams to send the message to the bot's endpoint
The endpoint has to be HTTPS, meaning you have to proxy Hubot. The endpoint also has to be publicly available, or at least available to the Microsoft IP range. However, I found there is authentication that happens:
while anyone can technically post to your api/messages endpoint, the message coming in has a JWT token signed by AAD to verify that it came from a proper source. The botbuilder SDK (package that this adapter relies on) does this check for every message. Every response is also authorized with a JWT token that your bot retrieves from AAD for us to verify as well.
Reference:
https://github.com/Microsoft/BotFramework-Hubot/issues/25#issuecomment-402223551

Asking the user for settings when enabling an Alexa Skill

I am working on an alexa skill which uses an external web service which requires an API key.
I can't find for the life of me where I can add this property in so that when the user enables the Alexa skill (I haven't got as far as publishing yet but I assume there is a property I can set somewhere as well for testing) they can add their API key and I receive this within my node.js lambda function and extract it and use it for my post request to the web service.
I know there is an Amazon Account Linking Service, but the web service I am using doesn't support this type of login I believe, their API is only accessed by sending a header containing the API key. Therefore I need a way for the user to be able to store somewhere their API key so I can then post this to the web service from the lambda code.
I'm not clear on how you expect the user to 'add their API key'.
The only built-in UI is the cards that your skill can push to a user but these are very limited and can't request information from the user.
Amazon does not show the user any sort of configurable settings for the skills.
And you have noted account-linking and that it does not address your needs.
So you could either ask the user to say the API key, which would be much too error prone unless it is unusually short, or you will need to direct the user (probably via a card) to your own website where they will provide their API key.

Resources