This article applies only to standard apps. If you are making a custom app, go to Validation - custom app
In addition to meeting our business requirements for standard apps, your app must go through a technical certification that focuses on how your application handles confidentiality, integrity, traceability, and availability.
We, therefore, seek information from you about these areas so we can validate and test against key criteria.
Whenever you think that your app meets all our requirements, please fill out the form Submit app for certification >
Why we test and certify each app
The motivation behind the certification process is to ensure that your app, when running, does not cause problems for either your customers or our customers.
Following the guidelines also ensures that the application follows the fundamentals that make your product distributable as a standard application in the SuperOffice marketplace.
Simply put, when the apps are of high quality, secure and easy to use, more customers will use them and their overall experience will be a good one. Happy customers are good for everyone.
For the same reasons, we also publish all certified apps in a beta program. This allows us to gain some early customer experience even before all details around the onboarding or commercial issues are in place.
The certification process
We check and validate your app in all three environments, and it needs to be passed in the first before it is moved and made available in the next.
Round 1: SuperOffice Operation Development environment (SOD)
You develop your app in our SuperOffice Operations Development environment, also known as SOD. This is also where we perform the first tests of your application to verify that you comply with our rules.
In particular, we look to understand and check:
- Provisioning – what you add to the database.
- Whether you write to the database without the user being logged in (outside the user's context). If so, do you use a system user for your communication with the database?
- Data added to the customer database, specifically web panels, will they leak confidential information if the URLs are sent out to unknowns? Do you protect data shown in the web panels?
- Then we run normal user tests, like how the user will use the app, to see what it will do against the customer database. We need your input on these test cases since you are the one who knows your app best.
In all these tests we watch closely how this affects the load on our environment, like our web servers and SQL servers.
- If there are any errors in our logs caused by your app, then these must be solved.
- What happens on your side if the app is no longer authorized to connect to the customer's database.
- Do you keep logs of the activities done by your app for historical lookup if the customer has questions about what happened?
- De-provision – do you clean up if the customer wants to remove the app. The data added is of course still there, but if you add web panels, buttons and so on, it should be removed if they no longer want to use your app.
We also look at your documentation to the end customer, like your support resources (web page or email/phone number) and technical product description for the end user. We both want the customer to be able to help themselves and to be able to contact your support organization directly if they need more help.
Round 2: Stage environment
When we have run successful tests in SOD, we move your app over to our Stage environment. Stage is identical to our production environment.
Note that you may not publish anything directly from our SOD environment to our production environment. This is the same release strategy we follow with our own software.
In Stage, we re-run the main tests of provisioning, user tests, performance, and deprovisioining as we did in SOD.
After a successful re-test here, we will send a handover to the Watchcom security audit which also needs to be completed before the app is moved into production.
Round 3: Production environment
Finally, we do one last test in our production environment before your app is published in the App Store.
During this time you should also have finalized your commercial app entry in our store so that as soon as the certification is approved, you can be present in the store.
During all tests, we will keep a close dialog with your technical contact, who will also be the one starting up the tests on the day we schedule the tests.
Key certification requirements:
The tests aim to look at a range of issues as well as the general user experience. Each app may be different in their features and technologies, but there are a number of key requirements that must be met:
- You must use federated authentication and validate all tokens you receive back from us.
- You may not store any user credential authentication information in your application. If you want to be able to write to the database when the user is not logged in then you must use a system user.
- Is your cloud secure and running with a valid certificate? Your redirect URL must run HTTPS. You may analyze your own site here: https://www.ssllabs.com/ssltest/analyze.html
- A security audit must be performed on your cloud and app by a professional security company and all red flags must be fixed before we publish your app in beta.
- Always keep in mind the OWASP top ten list.
Your code – your cloud
- SuperOffice AS will not host any partner DLL assembly in the website's bin directory on online.superoffice.com. This means that any code must be run in your own secure cloud.
- Make sure that the user gets enough feedback, both during provisioning and use. This may be by using help files or link to your website.
- SuperOffice AS will log who calls us and when, but we do recommend that your application also log information about the use of your app.
- While we understand that you want to give your customers the best performance possible, it is important to remember that the resources are shared with more customers. We do not yet have throttling in place, but during the certification tests, we will monitor how your app use recourses on our web servers and SQL servers.
For more information on these topics, please read the article Certification requirements.
Note: This is a living document, and new apps presenting new questions may result in new rules at any time.