Making access easy but secure

So following on from my earlier article, Policies let your teams play safe, I have been given another challenge: Can we give our users single sign on now that each team can play safely in their own Oracle Cloud Infrastructure compartments?

Single sign on delivers a number of really important benefits. Firstly, the user experience is much smoother and seamless as users don’t get prompted for multiple passwords and don’t have to remember even more passwords. More importantly, single sign on eliminates the need to manage multiple stores of identities. This can be a big overhead for administrators and sometimes open up additional risks. Finally, an enterprise wide identity solution can often provide additional capabilities can be leveraged by your Oracle Cloud Infrastructure.

Oracle Cloud Infrastructure supports a couple of different flavours of enterprise identity solutions: Oracle Identity Cloud Service and Microsoft Active Directory Federation Service (ADFS). The great news is that Oracle Cloud Infrastructure is pre-integrated with Oracle Identity Cloud but you’ll probably want to provide finer grained access.

In this example, I’ll explain how configure Oracle Identity Cloud Service as an external identity provider for Oracle Cloud Infrastructure. I will also explain how to map groups from the external identity provider to Oracle Cloud Infrastructure so you can use the policies from my earlier article, Policies let your teams play safe.

At a high level this is what we’ll do:

  • Setup trust between Oracle Identity Cloud and Oracle Cloud Infrastructure using the Client ID and Secret
  • Create a couple of Marketing groups and users then assign each group to different users
  • Map the groups from Identity Cloud to Oracle Cloud Infrastructure
  • If you haven’t tried my earlier article, you’ll need setup policies as described in Policies let your teams play safe
  • Try it out by logging in as one of the Marketing Users

The good news is that this is a one-off configuration to ensure that your Oracle Cloud Infrastructure service and your Identity Cloud Service trust each other. Once you have configured the trust and mapped your groups the users will have a seamless SSO experience with policies enforced by Groups.

You will need an active cloud subscription and create a Compute Instance which you can do from the Cloud Services Console below. Oracle Identity Cloud is enabled by default. Don’t worry if you haven’t got an active subscription because you can sign up for a trial for free.

So let’s get started. Firstly login to the Oracle Cloud Services console with credentials provided by your administrator or from Oracle Cloud if you’re the super user. The Cloud Services console should look like my screenshot below.

Compute Application Information

You’ll need to get the Application Client ID and Client Secret from Identity Cloud so that you can map the groups later in this article.

Click on the Users icon at the top of the screen (I’ve circled it in red above).

Click on the Identity Console button.

Click on the Menu Button next to the Oracle logo in the top left of the screen

Click on Applications and search for COMPUTEBAREMETAL

Select the COMPUTEBAREMETAL application and click on the Configuration tab

Copy the Client ID and Client Secret from the General Information section. You’ll need to click on the Show Secret button to see the Client Secret. Remember that this information is very sensitive – DON’T POST IT ON BLOGS like this or github etc. The screenshot below shows what to copy (with bits obscured to protect the innocent).

Create Marketing Groups

In my earlier article, Policies let your teams play safe, I created a couple of groups for the Marketing department in Oracle Cloud Infrastructure: Marketing-Users and Marketing-Admins. I create these groups in my external identity provider so that when users login from Identity Cloud, the groups associated with the user will be passed onto Oracle Cloud Infrastructure. This is how Oracle Cloud Infrastructure knows which policies to enforce.

Click on Groups -> Add

Create a group called Marketing-Users

Give it a description and optionally check the Users can request access checkbox. This checkbox allows users who have already been registered in Identity Cloud to request access to the Marketing-Users group. In my example, I don’t mind anyone in the enterprise using the Marketing resources. Of course, you may decide this is appropriate in the real world.

Click Finish

Click Add

Create a group called Marketing-Users

Give it a description but this time don’t check the Users can request access checkbox. In my example, admin level access is privileged so users are not permitted to request access to this group.

Click Finish

Assign the groups to some users

Go and create a couple of users (I’m assuming you can work this out yourself). Click on Users in the menu and go from there. Assign one user to Marketing-Users and another user to Marketing-Admins. These will be used later to tryout your SSO and make sure that the policies from my earlier article are applied to these new users.

You’re done with Identity Cloud for now so log out.

Map the Groups

Mapping groups from the Identity Provider (Oracle Identity Cloud Service in this case) to groups in Oracle Cloud Infrastructure is the secret sauce that allows you to enforce fine grained access controls. For example, by assigning a Marketing Admin group to a user in Identity Cloud, you’ll then be able to restrict access for that user to Marketing resources using policies defined in Oracle Cloud Infrastructure.

Oracle Cloud Infrastructure is automatically federated with your instance of Oracle Identity Cloud Service. All you need to do is map the groups from Identity Cloud (aka the Identity Provider) to groups in Oracle Cloud Infrastructure.

Login to the Oracle Cloud Services console again with credentials provided by your administrator or from Oracle Cloud if you’re the super user. This is the console that you first logged into at the beginning of this article.

Click on the Compute instance

Click on the Open Service Console button

TIP: I find it very useful to create a bookmark for this URL in my browser. I’ll refer to this later as the Oracle Cloud Infrastructure Console.

Click on Menu -> Identity -> Federation

Select the active Identity Provider. It should be called something like “OracleIdentityCloudService”.

Click on Edit Mapping

Enter the Client ID and Client Secret that you saved earlier and click Continue

Click on Add Mapping

Select Marketing-Users from IDENTITY PROVIDER GROUP drop down.

Select Marketing-Users from the ORACLE CLOUD INFRASTRUCTURE GROUP drop down.

Click on Add Mapping

Select Marketing-Admins from IDENTITY PROVIDER GROUP drop down.

Select Marketing-Admins from the ORACLE CLOUD INFRASTRUCTURE GROUP drop down.

Click on Submit

Log out!

Create Some Policies

If you haven’t followed my earlier article then now is the time to do so. Go have a look at Policies let your teams play safe.

Try it Out!

Click on the Oracle Cloud Infrastructure Console bookmark that you saved in your browser earlier.

Click on Continue in the Single Sign-On (SSO) box. This will take you to Oracle Identity Cloud.

Login as the Market Admin user that you created in Oracle Identity Cloud Service earlier in this article.

Marketing Administrators Can’t See Non Marketing Resources

We should see a Forbidden message

Marketing Administrators Can See Resources in the Marketing Compartment

Now select the Marketing compartment from the drop down on the left

We should see a different message now: “There are no Autonomous Data Warehouses in Marketing that match the filter criteria.”

This is because the Marketing Policy allows us to see objects in the Marketing Compartment, however, we haven’t created any warehouses in the Marketing Compartment yet.


Conclusion

Integrating Oracle Cloud Infrastructure with Oracle Identity Cloud gives you big benefits in terms of user experience and significantly less time managing users. You can extend the benefits even further with Policy Based Multi Factor Authentication.

Policies let your teams play safe

Earlier today I was given a challenge by my colleagues. Recently Oracle released the Autonomous Data Warehouse and we have a lot of excitement from customers, partners and internal folk alike. This excitement is driving a lot of innovation right now, but that also brings some challenges. The last thing we want is the Marketing team to mess with Finance resources. How do we make sure different teams don’t step on each other’s toes?

Oracle Cloud Infrastructure provides two powerful capabilities, Compartments and Policies, to help make sure that different teams can play safe without stepping on each other’s toes.

Compartments give us the ability to isolate one collection of resources from another collection while Policies allow us to specify who can access which resources and how. Typically, access is granted at the group and compartment level, which means you can write a policy that gives a group a specific type of access to a specific compartment.

In this example, I’ll explain how to isolate a set of resources for the Marketing Department. To set the scene, let’s suppose that Finance needs a data warehouse for analysis and projections. Here’s the high level set of tasks needed to get the data warehouse available:

  • Create a compartment – this isolates my resources from other teams and projects in the organisation
  • Create two groups –
    • Marketing Users who simply use the data warehouse
    • Marketing Admins who manage the data
  • Create a set of tags so that Marketing Admins can associate data with Marketing Events and Campaigns
  • Create a policy that determines who can do what in the compartment
    • Campaign ID
    • Event
    • Marketing Contact

So let’s get started. Firstly login to the Oracle Cloud Infrastructure console with credentials provided by your administrator or from Oracle Cloud if you’re the super user. Note that your Cloud Infrastructure console URL may be different depending on which region you want to use.

Create a Compartment.

Click Menu –> Identity -> Compartments

Create a compartment called Marketing

Click create Compartment

Create Marketing tags

Tags are a great way to attach information about resources (e.g. ADW Instances). In my example I want to allow administrators to tag resources with Event Names, Campaign IDs and Owners.

Click on Menu -> Governance -> Tag Namespaces -> Create Namespace Definition

Select the Marketing compartment from the drop down on the left side of the screen.

Click on Create Namespace Definition

Select Marketing compartment

Enter Marketing as the NAMESPACE DEFINITION NAME

Select the Marketing namespace

Click on the Create Tag Key Definition

Create the following Tag Keys:

CampaignID

Event

Owner

It should look like this:

Create Marketing groups

Marketing users and administrators are managed by Groups.

Click on Menu -> Identity -> Groups ->

Click on Create Group

Name: Marketing-Admins

Description: Administrators of resources in the Marketing compartment

You might also want to add a marketing tag like Owner

Click on Submit

Click on Create Group

Name: Marketing-Users

Description: Users of resources in the Marketing compartment

You might also want to add a marketing tag like Owner

Click on Submit

Here’s a screenshot of the Marketing-Admins group:

Create the Policy

Objective

So basically, I want Marketing users to be able to use any resources that have been created in the Marketing compartment. I also want to prevent Marketing users from using resources outside the Marketing compartment.

More importantly, I want to make sure Marketing Admins can only manage resources that belong to the Marketing compartment. I also want Marketing Admins to be able to add any user in the organisation to the Marketing group.

This allows the Marketing Department to create resources quickly, use them and get rid of the resources when they’re done. All of this can happen very quickly safe in the knowledge that they can’t mess up corporate resources owned by other departments.

Steps

Click on Menu -> Identity -> Policies

Select the Root compartment from the drop down on the left side of the screen. The Root compartment will appear as the Tennancy ID followed by Policies are best left in the Root compartment so that they can be applied to objects like users and groups.

Click on Create Policy

Name:    Marketing

Description: Restrict Marketing administrators and users to the Marketing compartment.

Policy Versioning: KEEP POLICY CURRENT

Statement: (Click on the + to add each statement below)

Allow group Marketing-Admins to inspect users in tenancy

Allow group Marketing-Admins to inspect groups in tenancy

Allow group Marketing-Admins to use users in tenancy where target.group.name=’Marketing-Users’

Allow group Marketing-Admins to use groups in tenancy where target.group.name=’Marketing-Users’

Allow group Marketing-Admins to manage all-resources in compartment Marketing

Allow group Marketing-Admins to manage tagdefinitions in tenancy

Allow group Marketing-Admins to manage tag-namespaces in tenancy

Allow group Marketing-Admins to use tagdefinitions in tenancy

Allow group Marketing-Admins to use tag-namespaces in tenancy

Allow group Marketing-Users to use all-resources in compartment Marketing

Try it out!

Create a new user in Oracle Cloud Infrastructure

Click on Menu -> Identity -> User

Create a user

Create a password for the user

Assign the Marketing-Admins group to the new user

Sign Out

Login as your new user

Reset your password

Now we shouldn’t be able to see any Autonomous Data Warehouse instances in the Root compartment because the Marketing policy doesn’t allow it:

Click on Menu -> Autonomous Data Warehouse

Marketing Administrators Can’t See Non Marketing Resources

We should see a Forbidden message

Marketing Administrators Can See Resources in the Marketing Compartment

Now select the Marketing compartment from the drop down on the left

We should see a different message now: “There are no Autonomous Data Warehouses in Marketing that match the filter criteria.”

This is because the Marketing Policy allows us to see objects in the Marketing Compartment, however, we haven’t created any warehouses in the Marketing Compartment yet.


Conclusion

Policies, compartments and tags are really powerful capabilities that allow organisations to move to the cloud with much greater agility. Policies can restrict and enable access to resources across your organisation.

Your Place or Ours

Sometimes you just want to build a local environment on your own equipment simply because it’s quick and easy. But you soon realise that other people need access and resources get a bit tight (memory, CPU, etc). That’s when it makes sense to move it from your place into the cloud.

Just recently I realised how useful Oracle Virtual Box’s new export feature is for migrating local VMs into Oracle Public Cloud Infrastructure – Compute Classic. Oracle Virtual Box’s new export formats give me the ability to easily migrate Images to the Oracle Public Cloud where I can scale my environments as required.

Earlier this week I was building a new Oracle Identity and Access Management development environment on my laptop. This worked well from an initial build and configure perspective but there comes a time when I need to make this environment available to my Developers, Testers and other stakeholders. Running this image continuously on my laptop quickly becomes impractical even for development teams.

Continue reading “Your Place or Ours”

Hey Dude, where’s my keys?

I was asked recently to speak at a Developer forum about ways to make life easier for developers to secure their applications in the cloud. The session was great and lots of questions were asked but perhaps the most surprising question asked was from a developer who wants to integrate a custom application with Oracle Identity Cloud. This developer needs access to the public keys used by Identity Cloud Service before a user has authenticated to the service. More importantly, the developer needs the keys represented in the JWK format. According to the specification, a JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.

There are very valid reasons why the developer needs access to the public keys without an authenticated session. Public keys let someone verify the signature on something signed with the associated private key or encrypt a message to send to you.

The developer asked Can I get a JWK from Oracle Identity Cloud Service without an OAuth Access Token?

The answer is simple… YES!!! There are two important API’s available in Oracle Identity Cloud Service

Continue reading “Hey Dude, where’s my keys?”

Policy Based Multi Factor Authentication

In my previous article, Securing Applications with Multi Factor Authentication I discussed how to roll out basic MFA. While this is great if your requirements are very straightforward, there are times when you’ll need a more sophisticated approach. One of the most common examples that I get asked about is how to challenge users for Multi Factor Authentication only when they are connecting remotely from home or when traveling.

In this article I use an example where the business requirement is to enforce MFA for people in the Customer Relations department who are accessing protected applications when they are not on the corporate network. I’ll explain how to configure policies and rules that allow users connected to the corporate network to login with just their User ID and Password, while users connected remotely will need to use Multi Factor Authentication to access protected applications.

Continue reading “Policy Based Multi Factor Authentication”

Securing Applications with Multi Factor Authentication

These days, passwords online are not strong enough by themselves to protect applications. Scandals about password breaches seem to happen on a regular basis. This is where Multi Factor Authentication (MFA) greatly reduces the risks associated with protecting information online. Multi Factor Authentication combines something you know (e.g. your password) with something you have (e.g. your smartphone). MFA can be used with SMS or a Mobile App on an iPhone, an Andriod phone or a Windows Phone. Using MFA on a smartphone significantly reduces the costs associated with older and more traditional MFA technologies like physical tokens because of the cost of delivery and administrative overheads.

Oracle Identity Cloud Service allows you to deliver Multi Factor Authentication quickly and easily. In this article I’ll walk through the steps necessary to enable Multi Factor Authentication using Oracle Identity Cloud Service(IDCS). Once MFA is enabled you’ll be able to use MFA with any application protected by your instance of Oracle IDCS. In my example, I’ll use the Oracle Mobile Authenticator App on an iPhone to protect applications as well as the User Self Service Console in IDCS.

Continue reading “Securing Applications with Multi Factor Authentication”

Multi Factor Authentication is Critical for Everyone

In today’s environment where systems run in the cloud and so much business and personal activity occurs online, passwords are not strong enough by themselves to protect applications. Scandals about password breaches seem to happen on a regular basis. It’s easy to find many case studies where passwords have been compromised as a result of malware, email scams and other techniques. The key point is that no matter how strong our passwords, no matter how much we educate our users, there will be situations where people are caught off guard and click on the wrong link, look at the wrong email or open the wrong document. Once this happens, our passwords can be compromised.

Continue reading “Multi Factor Authentication is Critical for Everyone”