In our recent Label Security presentation we used a feature called Proxy Authentication. This allowed us to connect to the database as one user, but proxy the credentials of another so that we can access resources that proxied user can see. Without this we wouldn’t be able to use Label Security with our OSB services. It’s been brought to my attention that this is a useful feature that others would be interested in, but it’s hidden within my other post. So I’ve extracted the material out here to its own post so it can be found easier. Enjoy!
So you’ve followed Oracle’s lead and started implementing REST services in Oracle Service Bus. But you very quickly run into a problem, how do I get my webpages to access these services via Ajax when they are hosted on different domains (or ports). This is generally forbidden in most browsers (as it violates the ‘same origin policy’, ie: you can only access resources in the same domain as you). The most common recommendation to resolve this issue is to enable CORS (Cross Origin Resource Sharing). Basically you just set a header in the response from the remote service that lists the domains that are allowed to request from this resource. If the web page is in that list the browser will allow the resource to be accessed.
Getting this to work in OSB is actually pretty easy and will mean that your OSB services don’t have to be on the same domain as your web pages. Read on to find out how.
Another customer success story and another amazing cake! Yesterday we celebrated the launch of the Document Verification Service at ComSuper. This was the first service delivered on ComSuper’s new Oracle Service Bus platform and is hopefully the first of many.
The DVS is managed by the Attorney-General’s Department and is one of the key initiatives of the Council of Australian Governments’ National Identity Security Strategy. ComSuper checks the information on identity credentials against the records of the issuing agency in real time to inform decisions that rely upon the confirmation of a person’s identity and is a key tool to eliminate use of fraudulent identities.
So by now you’ve seen how to install Label Security (here), configure a policy (here) and create a UI to access the data (here). Particularly in the UI post, you would have seen how Label Security helps to simplify our application development, as we no longer have to worry about configuring data security, the database takes care of it for us. Whilst a UI is a great way to access our data and demonstrates a common use case, it’s not the only way to access our data. So in this post we are going to demonstrate how to create a web service that will talk to our database and return the correct documents for each user.
If we weren’t using Label Security, we’d have to add some significant logic to poll the database for the security permissions of the user (ie: JCooper has Top Secret access, but CDoyle can only see Secret Narcotics documents). We’d then need to apply that to our query to return the documents. Whilst this will work, what happens if the developer writes the query incorrectly and some users start seeing documents they shouldn’t? Or what happens if the service is compromised and a hacker gets access to the underlying database using the application database credentials. This poses a significant risk to our organisation and it’s data security. With Label Security we can avoid all this as the service just has to query the database and pass down the user credentials. The database will take care of the rest, there is no opportunity for the developer to mess up the query or if the user account is compromised only the documents that user had access to will be affected.
I’ve uploaded the OSB project that we will create below to GitHub. You can access it here: https://github.com/Joelith/SecureOSB. To get it working, import the project into JDeveloper and configure the database source in WebLogic (detailed below). Otherwise read on to see how it’s all put together
When you think virtualisation, you generally think of hypervisors like VMWare, Virtual Box etc. These work by effectively emulating an entire operating system on top of another operating system. But did you know there’s actually another option, one that is generally better performant and where the images take up less space (who’s tried to share a VM with a colleague remotely before. Sending a 40Gb file is not easy!)? This option is called ‘containers’ and it’s actually been around for a long time (it’s been in Solaris for years and has recently made it’s way to Linux).
Containers work by sharing the host operating system with the container, but the container has it’s own file system and can’t access the resources on the host. Virtualisation without the overhead of emulating an operating system! One of the easiest ways to get started with containers is to use Docker. Docker provides an easier way to use containers and manage the images. To demonstrate how Docker works and how we can use it to create containers of Oracle products check out this post over at the RedStack blog that I co-authored with Edwin Biemond and Mark Nelson
If you’ve been following along in our series of Oracle Label Security posts (Part 1, Part 2) you should now have a table of ‘documents’ that depending on the users permission will return different sets of documents. In this post we’re going to add a UI so that we can see how Label Security makes application development easier by freeing us from having to worry about security in the application. We won’t actually be doing any database work (that’s been done in the previous posts) and will just focus on getting a simple UI up. You could use any language to build this UI as long as it can connect to the Oracle database (generally through ODBC), which is pretty much of all of them. For this example we are going to build a NodeJs application with a Bootstrap UI. It will be a good demonstration of how to connect NodeJs and the Oracle database together.
The completed application is available on GitHub: https://github.com/Joelith/SecDocNode. Read on to see how it’s built
In the previous post we outlined Oracle Label Security and set it up in our 12c database. Now we are actually going to implement the policy against our table. What we want to produce is a table (let’s call it ‘documents’) that will store sensitive data. That data will either be ‘Top Secret’ or ‘Secret’ and belong to one of a number of groups or compartments (‘Fraud’, ‘Narcotics’ and ‘Terrorism’). We want users to be able to log in and not have to worry about security (nor do we want them to be able to look at documents they don’t have access to). Basically we want every user to be able run ‘SELECT * FROM documents’ and get only the documents they are supposed to see.
I’ve uploaded a script to GistBox that will run all the SQL below. It contains some clean-up before it runs the SQL below, so you can run it as many times as you like. Just modify all the defines at the beginning of the script to match your environment and then run the script in sqlplus with @secdemo