I want to add WebAuthN as an option for multi factor authentication to an Angular & Spring application. I use the WebAuthN java-webauthn-server library from Yubico.
What is the best way to integration test my WebAuthN server, without a hardware client? Is there any software that can handle the cryptography in an automated test? I want to run these tests automatically in the CI/CD pipeline (GitLab).
In a best case scenario I want to be able to test the whole process, creating credentials as well as logging in. An alternative scenario could be that I use known credentials in the backend and only log in with these.
My API is REST/JSON based, with relying party, user, challenge, pubKey etc...
My integration tests are Java based (spring boot starter test)
I am mainly interested in how to integration test the server without the client side. Are there utility programs or libraries that can handle authenticators and return the correct data/json objects?
I have looked at Testing WebAuthn via REST tool, however, I am not interested in testing the specification, since I am using a library, I only want to ensure that I applied the library correctly to my code.
If you are only interested in testing the server side, you can write a simple webpage with buttons that exercise your endpoints and call navigator.credentials.(create|get). You can then instrument a browser using Selenium 4+, set up Virtual Authenticators, and run tests against that webpage. Take a look at the selenium tests for an example. The code to set up the authenticators looks like this in java:
VirtualAuthenticatorOptions options = new VirtualAuthenticatorOptions();
options.setTransport(Transport.INTERNAL)
.setHasUserVerification(true)
.setIsUserVerified(true);
VirtualAuthenticator authenticator =
((HasVirtualAuthenticator) driver).addVirtualAuthenticator(options);
Pay attention to setting up the authenticator with the right settings to match your webauthn call. You should pick the right user verification support, resident keys support, and internal (i.e. platform) vs usb / nfc / ble (i.e. cross-platform) transport.
If you're using an older version of selenium, you'll have to manually define the commands yourself. The code should look like
browser.driver.getExecutor().defineCommand(
"AddVirtualAuthenticator", "POST", "/session/:sessionId/webauthn/authenticator");
// ...
Command addVirtualAuthCommand = new Command("AddVirtualAuthenticator");
addVirtualAuthCommand.setParameter("protocol", "ctap2");
addVirtualAuthCommand.setParameter("transport", "usb");
browser.driver.getExecutor().execute(addVirtualAuthCommand);
Running selenium tests might take a bit of work if you aren't already using it for integration testing. However, this implementation will very closely match reality. From the browser's perspective, the virtual authenticator is real hardware. The response from the authenticator will be processed by the browser as if it was real.
At the moment, only chromium based browsers support Virtual Authenticators.
Related
I am implementing some integration tests here between my mobile apk and the server API. I am using JAVA and Robotium for the UI tests. I need send some Json requests to the server and check if the behaviour on the app is correct after this change.
I have suggested create the jsons in a script and inside of the a step of the scenario (Given step) send this json to the server, but this would duplicate the effort when maintaining the scenario on server automation (Jmeter scripts) and mobile automation (Cucumber-JVM and Robotium).
Is anyone has an idea how I could implement integrated tests between the mobile app and the server API without duplicating the scenarios on both of the automations ?
I found a strategy to do the integration tests between the app and the server API, google suggests Hermetic tests:
http://googletesting.blogspot.co.uk/2012/10/hermetic-servers.html
http://googletesting.blogspot.co.uk/2015/03/android-ui-automated-testing.html
Some good points are:
- You are not mocking the server anymore
- You don't need to worry about to maintain the mock server and the test
- You are running without need a network connection
- The tests are more reliable
I have a service that calls out to a third-party endpoint using java.net.URLConnection. As part of an integration test that uses this service I would like to use a fake endpoint of my own construction.
I have made a Spring MVC Controller that simulates that behaviour of the endpoint I require. (I know this endpoint works as expected as I included it in my web app's servlet config and hit it from a browser once started).
I am having trouble figuring out how I can get this fake endpoint available for my integration test.
Is there some feature of Spring-Test that would help me here?
Do I somehow need to start up a servlet at the beginning of my test?
Are there any other solutions entirely?
It's a bad idea to use a Spring MVC controller as a fake endpoint. There is no way to simply have the controller available for the integration test and starting a servlet with just that controller alongside whatever you are testing requires a lot of configuration.
It is much better to use a mocking framework like MockServer (http://www.mock-server.com/) to create your fake endpoint. MockServer should be powerful enough to cover even complex responses from the fake endpoint, with relatively little setup.
Check out Spring MVC Test that was added to Spring in version 3.2.
Here are some tutorials: 1, 2, 3
First I think we should get the terminology right. There are two general groups of "fake" objects in testing (simplified): a mock, which returns predefined answers on predefined input and stubs which are a simplified version of the object the SUT (system under test) communicates with. While a mock basically does nothing than to provide a response, a stub might use a live algorithm, but not store it's results in a database or send them to customers via eMail for example. I am no expert in testing, but those two fake objects are rather to be used in unit and depending on their scope in acceptance tests.
So your sut communicates with a remote system during integration test. In my book this is the perfect time to actually test how your software integrates with other systems, so your software should be tested against a test version of the remote system. In case this is not possible (they might not have a test system) you are conceptually in some sort of trouble. You can shape your stub or mock only in a way you expect it to work, very much like the part of the software you have written to communicate with that remote service. This leaves out some important things you want to test with integration tests: Was the client side implemented correctly so that it will work with the live server. Do we have to develop work around as there are implementation errors on the server side? In which scale will the communication with the remote system affect our software's performance? Do our authentication credentials work? Does the authentication mechanism work? What are the technical and conceptual implications of this communication relationship no one has thought of so far? (Believe me, the latter will happen more often than you might expect!)
Generally speaking: What will happen if you do integration tests against a mock or a stub is that you test against your own understanding of how to implement the client and the server side of communication, and you do not test how your client works with the actual remote server or at least the best thing next to that, a test system. I can tell you from experience: never make assumptions on how a remote system should behave - test it. Even when talking of a JMS server: test it!
In case you are working for a company, testing against a provided test system is even more important: if you software works against a test system and you can prove it (selenium is a good helper here, as well as good logging, believe it or not) and your software does not work with a live version, you have a situation which I call "instablame": it is immediately obvious that it is not your fault the software isn't working. I myself hate fingerpointing to the bone, but most suits tend to ask "Who's fault was it?" even before "Can we fix that immediately?" and way before "How can we solve that problem?". And there is a special group of suits called lawyers, you know ... ;)
That being said: if you absolutely have to use those stubs during your integration tests, I would create an own project for them (let's say "MyProject-IT-Stubs" and build and run the latest version of MyProject-IT-Stubs before I run the IT of my main project. When using maven, you could create MyProject-IT-Stubs with war packaging, call it as a dependency during the pre-integration-test phase and fire up a jetty for this war in the same phase. Then your integration tests run, either successful or not and you can tear down the jetty in the post-integration-test phase.
The IMHO best way to organize your project with maven would be to have a project with three modules: MyProject,MyProject-IT-Stubs and MyProject-IT(declaring dependencies on MyProject and MyProject-IT-Stubs. This keeps your projects nice and tidy and the stubs do not pollute your project. You might want to think about organizing MyProject-IT-Stubs into modules as well, one for each remote system you have to talk to. As soon as you have test access, you can simply deactivate the according module in MyProject-IT-Stubs.
I am sure according options exist for InsertYourBuildToolHere.
I have an app that currently uses the com.google.appendinge.api.appidentity.AppIdentityService to facilitate authentication & authorization for using the same app's [ie. same account] spreadsheet data via the SpreadsheetService API. Works great in production mode deployed to the GAE environment. But for obvious reasons, it doesn't work (authentication error, no surprise there) running in my development appengine environment.
My question is: is it possible & 'supported' to configure one's local development server to use the necessary key & certificate info to enable the AppIdentityService to work as intended?
I read the article https://sites.google.com/site/oauthgoog/authenticate-google-app-engine-app and I understand it to suggest that it is possible but I be mis-understanding key points & would appreciate any feedback pro & con regarding this.
In a perfect world, I'd like my testing env to mimic the production mode as closely as possible. I am also considering using the 'normal' oauth2 web app authentication in my testing env but would prefer sticking with using AppIdentityService if at all possible.
I suspect the com.google.appengine.api.appidentity.dev.LocalAppIdentityService class in the appengine-api-stubs.jar is the intended technique but has anyone else also used this to provide AppIdentityService authentication within a development server? My initial assumption is that replacing the class com.google.appengine.api.appidentity.IAppIdentityServiceFactoryProvider found in com.google.appengine.spi.FactoryProvider to use my own factory class using the above LocalAppIdentityService class. Or am I barking up the wrong tree?
Using GAE SDK 1.8.8 for Java.
When running under the local dev server, the GAE Java App Identity API calls the GoogleCredentials library to retrieve the default application credential.
The environment variable GOOGLE_APPLICATION_CREDENTIALS is checked. If this variable is specified it should point to a file that
defines the credentials. The simplest way to get a credential for this
purpose is to create a service account using the Google Developers
Console in the section APIs
& Auth, in the sub-section Credentials. Create a service account
or choose an existing one and select Generate new JSON key. Set
the environment variable to the path of the JSON file downloaded.
If you have installed the Google Cloud SDK on your machine and have run the command gcloud auth login, your identity can be used as
a proxy to test code calling APIs from that machine.
If you are running in Google App Engine production, the built-in service account associated with the application will be used.
If you are running in Google Compute Engine production, the built-in service account associated with the virtual machine instance
will be used.
If none of these conditions is true, an error will occur.
It looks like option #2 is probably easiest for you (run gcloud auth login to have your code use your Google account for authentication when run locally), but you could also do #1.
I have been working with GAE's PHP dev server and had the same issue with the AppIdentity service not working correctly. In PHP you can get around this by setting the $_SERVER['APPLICATION_ID'] to dev~yourapplicationid. I am sure there must be a way to do the same in Java, you just need to prepend dev~ to the start of your application ID to work with the dev environment.
How do I write integration test for an application that interacts with website ?
More specifically I have an application that interacts with Flickr website.During the OAuth authorization process flickr website display's the verifier code which the user has to copy and paste into my application. Now how do I automate this process so that I can test the application automatically.I am using swing for GUI.
Writing automation that depends on external services can be tricky. For something like this, I would advise you to set up a mock service, or some other way of using canned responses.
I've had success doing this a couple of ways:
Writing an external mock service, using something like bottle.py. This has the advantage of requiring little to no modification to your existing codebase, but obviously requires a bit of work to ensure that this external process is managed correctly as part of your test suite, especially if you are running tests in a CI environment.
Using dependency injection, you can write mock network components, and swap the real network components for your mock components for testing. I recommend this approach, but it will require a bit of modification to your codebase.
I am working on a Java web app with unit tests that deploy the app in Jetty. I use HtmlUnit to hit the app and do some high level tests. I set it up so that I can use a singleton probe to modify my system configuration and add a "test" flag--This is handy because I want to be able to run some tests without having to authenticate an actual user or check user roles.
However, it seems like it could open the door for vulnerability when the app is deployed. I'm looking for suggestions about how to make this "back door" a little more bullet proof. I could use a mock object to handle this, but I think that still leaves the back door exposed.
I have user accounts specifically for testing in all of my environments. I create them using the real registration process, nothing hand-made.
This bypasses your issue, allows me to test the signin process, and if needed I create multiple users with different traits/roles which I can test against.
Because the users are under my control, they remain consistent and match the expected test results.
Use special parameter that is long enough to assume. For example GUID. It could be even hard-coded in your application. All tests will append this parameter to each URL they are using. You can check this parameter using special HttpFilter and turn the test mode on.
Throw some kind of security around the process you use to change the app over to Test mode - Basic Authentication for that page, or something. This can all be configured directly in web.xml.