Oracle Mobile Cloud Service: team members accessing APIs

Oracle Mobile Cloud Service is setup around different personas. When you login to MCS you see a list of roles.


The Mobile App developer is the developer that is creating a mobile application and is using APIs that are exposed in MCS. The Service developer is the developer that creates the APIs, connectors etc.

This distinction is very useful: it helps in making sure the documentation is targeted to the right people and the content is organized in a way that makes sense for these different personas.

Sometimes, however, it does not work as well. As I discussed in an earlier post: the command line tools to deploy and test services is hidden in software that is targeted at mobile app developers.  In this post I want to discuss another use case that is not that obvious apparently: a service developer calling an API.

In our project we are creating APIs for several different mobile app developers. Before we publish an API and a mobile backend we want to test this mobile backend. We secured the APIs with security roles, because we want to make sure that APIs for internal use are not accidently exposed to external companies.  To be able to test the API, we had to assign the correct role to the team member. This is when the challenge started.

Assigning roles to users in MCS
There are two ways of assigning roles to users for MCS. The first method is using the MCS Mobile User Management, which can be accessed using the mobile portal ui:

Manage users and roles from the MCS portal

The second way is using the services dashboard, using the "Users" tab and clicking "manage roles" for a specific user:

Manage roles of a user using the "users tab" from the service dashboard

But before you can assign the role, you have to go to the user management part of the MCS and create a role in a realm. This is described in the documentation of MCS: "Set Up Mobile Users, Realms and Roles". It also describes naming conventions, for example for roles: 

"The naming convention for Oracle Cloud custom roles that represent MCS mobile user roles is: {serviceName}_MobileEnvironment_{rolename}. For example, for a role named “APIRole” in the environment with service name “poeo342ed” the custom role in Oracle Cloud would be poeo342ed_MobileEnvironment_APIRole." 

Then you can create a new user account for the tester and assign the newly created role to this user. (S)he then uses account after logging into MCS and changing the default password to test the API from postman, adding the username and password as Basic Authentication to the header of each call.

This all works very nicely. But we wanted to assign this role to ourselves. However, the users that were set up as team members did not show up in the MCS User management list of users. 

So I navigated to my services dashboard again and clicked on the tab "custom roles". Sure enough the role I just created was there, so I assigned my own user to the role and added my username / password to the Postman API call.
The result: "Unauthorized"

Solution

Users should not only be assigned to a role to access an API, they should also be part of the realm that is associated with the mobile backend. Unless, of course you use anonymous access, which does not work when you are securing your APIs with roles.
In our example we did not explicitly create a realm, so the mobile backend was associated to the Default Realm. We created the new tester in the default Realm, so this 'role' was automatically assigned to this user. The team members were not added to that realm and therefore did not show up in the list of users of the default realm.

We added the team members to the Default 'role', which corresponds to the realm in the mobile user management instance and voila! We can access the APIs :)

Role that represents the default realm in the mobile cloud service instance

Happy coding!

SOA Black Belt Workshop, Day 3: Architecture Internals

The topic of today was architecture internals.

Adapters: added value 

We were supposed to start with Fault handling, but the adapter session by Niall was preponed. He is a very good presenter, but unfortunately part of the slide deck was the usual marketing mumbo jumbo about how easy it is to integrate to any system. Since this day was "architecture essentials", I would have enjoyed a discussion on whether you want to use an adapter or build a 'proper' web service in Java more. The lab that accompanied this session was fun: we needed to fix the adapters that were configured beforehand. It was very much like what happens in real life.

Fault handling: expect the unexpected

The session on fault handling did not cover anything new as far as I am concerned. There is a lot of material out there that covers this topic. A lot of emphasis was placed on transaction management. This makes sense in the context of Fault handling, but it made the whole thing a bit repetitive. I would have preferred a shorter presentation about the different fault types and then a lab where we would actually build complicated fault handling scenario's (catchAll, fault policies, rolling back transactions). 

Security: we all have our role

Flavius explained the OPSS framework, virtual directory and how you can manage application roles in Enterprise Manager. This is particularly relevant in a human task service. A lot of people I know use groups in LDAP for that which makes the groups way to fine grained to be manageable. The other feature I was not aware of was using a light weight OVD by turning on 'virtual' in the WebLogic console.

Performance tuning essentials: a journey through the database 

Niall then traced all the database inserts and updates for a simple BPM process. It was interesting, but the title was misleading. The important part to remember is that every design decision you make in your composite as a developer will result in a write to the database. Performance is not always the key requirement, but it is something to take into account, of course.

Fusion apps: oer is the new irep

Niall showed us the Oracle Enterprise Repository for Fusion apps. It contains all the business objects, Web Services and other artefacts that you need to integrate with Fusion Apps. A lot of the integration is still based on an API model, rather than services. From a product vendor perspective it makes sense, but as an implementer you need to make sure that you don't expose all these fine grained services on your Enterprise Service Bus. 

Anti patterns are the new patterns

Ravi Sankaran did the last session over the phone. He presented a number of anti patterns, reasons why they occur and recommendations to follow to avoid them or only apply them if needed. The content was interesting but listening to somebody over the phone in a hot room (27 degrees and humid outside) after three days of training is not the best condition for knowledge transfer. I will have to take a look at the slides as soon as they are available.

The evening

Jürgen organized a boat tour and a really really nice dinner at a very interesting restaurant and handed everyone their blackbelt. It was a great way to talk to some new people and to see something of the city at the same time. 

Tomorrow is the last day, then it is back to reality again...