In this blog, we continue to explore the technical considerations for a Software as a Service application implementation.
In our previous blog, https://www.heug.org/p/bl/et/blogid=2508&blogaid=4096 we looked at some generalizations and now we’ll do a deeper dive into some of the specifics, looking at single sign-on, security and email. Again we’ve tried to be vendor agnostic and drawn on the experience of the Oracle Financials Cloud product at the University of Derby as well as the Oracle CX Cloud Suite at the University of South Australia.
So, let’s get right into it with single sign on (SSO). This is likely to be one of the easier items as modern cloud suites, in the main, support SAML2. As such it is very easy to integrate them with SAML2 identity providers. This involves collecting administration information for login URLs, redirect URLs and logout URLs and then giving your identity provider the details of the cloud system and vice versa. Here’s an example from our ERP Cloud here at Derby (you can click the image to enlarge in a new window):
A word of caution though, it may be that your cloud provider may need to perform the cloud side configuration and that is the case with Oracle. In the case of Oracle, to achieve SSO you log an SR for SSO setup having already set up your SAML2 identity provider first. There is a scripted SR to follow and once it is completed you will be given a test URL to make sure everything is working as it should. From there you update the SR to confirm prior to Oracle making the change live. Once live your users will use the “Company Sign In” button on the front page. This entire SR process can take a minimum of 2 weeks so you should address this early in your implementation.
Next up is email. Your cloud solution is likely to use email for notifications for things like approvals, expenses, actions required amongst a plethora of things. As your application is one of many instances running on the cloud it will have a spurious URL to access it. Emails will also be sent from this domain and it’s important to ensure you take necessary steps to allow these emails reach your users. You must also be careful not run into issues of authenticity. This is of particularly critical importance within a marketing application as you must preserve your institutions reputation.
This is achieved by a number of technologies:
- Sender Policy Framework (SPF)
- DomainKeys Identified Mail (DKIM)
- Domain-based Message Authentication, Reporting and Conformance (DMARC)
The complexities of each technology are a lot for this humble blog so suffice to bring these to your attention and suggest that further research is necessary. A particularly helpful introduction can be found on HigherLogic’s blog here - https://blog.higherlogic.com/spf-dkim-dmarc-email-authentication
You may also have to consider whitelisting the sending IP addresses to prevent communications ending up in junk mail. For instance, putting rules into Office365 tenancy to allow emails from ERP/CX cloud systems. This is added complexity especially, if as in the Office365 scenario, both systems are cloud based.
Finally, there’s the issue of “friendly” URLs. We all spend a lot of time educating users on phishing emails and “dodgy” looking website URLs. When you go to the cloud you won’t have a nice and friendly URL that users can recognise. Instead of something ending .edu, .ac.uk or your local equivalent, your cloud instance will be on you cloud providers URL – e.g. oraclecloud.com. Not only that, but with thousands of instances running in that cloud, you are very likely to get a randomised allocation of fully qualified domain name. In Oracle’s case this usually includes the data center preceded by the application and a random character string denoting the instance e.g.:
abcd.fa.us1.oraclecloud.com
where:
abcd - the instance name, known as your “pod”
fa - the product, in this case Oracle Financials
us1 - the data center hosting the instance
You must decide whether you want to “front” the cloud with a more friendly solution or include education of users as to the new changes as part of your implementation.
Security is also a big considerations. Sometimes with cloud vendors you need to get them to organise this side of things, and authorise them to be able to take out a certificate for a sub-domain of yours so they can manage it. You might need to also purchase something from the vendor SSL-wise, such as secure certificates from Oracle.
So there’s a lot to think about and although we’ve concentrated on Oracle examples throughout, these considerations are valid for any vendor/application. That said if you would like more details on the Oracle side of things, a good place to start is Doc ID 1529174.1 which outlines a “shopping list” of action items along with implementation times.