Understand Cloud Applications

About Cloud Applications

Cloud applications are web-based applications that function in the cloud. These applications can be accessed from anywhere, and at any time, over the web. Examples of cloud applications are Google, Salesforce, and Dropbox.

About Oracle and Custom Applications

Oracle applications are a complete and modular set of enterprise applications, engineered to be cloud-ready. In Oracle Cloud, you'll find a broad range of software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) applications. You can use these applications as part of a subscription-based service; there's no software license or hardware to buy and manage. Oracle handles all the supporting underlying technologies.

You can extend Oracle applications or even build your own custom cloud applications in Oracle Cloud. Custom applications are applications (such as a mobile application, a web page, a client application, or a server application) that you can integrate with Oracle Identity Cloud Service. By default, for security purposes, custom applications are trusted or confidential.

Oracle Identity Cloud Service leverages the power of OpenID Connect and OAuth to deliver a highly-scalable, multi-tenant token service for securing programmatic access to custom applications by other custom applications, and for federated SSO and authorization integration with these applications:

Use OAuth 2.0 to define authorization in Oracle Identity Cloud Service for your custom applications. OAuth 2.0 has an authorization framework, commonly used for third-party authorization requests with consent. Custom applications can implement both two-legged and three-legged OAuth flows.
Use OpenID Connect to externalize authentication to Oracle Identity Cloud Service for your custom applications. OpenID Connect has an authentication protocol that provides Federated SSO, leveraging the OAuth 2.0 authorization framework as a way to federate identities in the cloud. Custom applications participate in an OpenID Connect flow.

Using the OAuth 2.0 and OpenID Connect standards provides the following benefits:

Federated SSO between the custom application and Oracle Identity Cloud Service. Resource owners (users accessing the custom application) need a single login to access Oracle Identity Cloud Service plus all applications integrated. Oracle Identity Cloud Service handles the authentication and credentials itself, insulating custom applications. This capability is provided by OpenID Connect with OAuth 2.0.
Authorization to perform operations on third-party servers with consent. Resource owners can decide at runtime whether the custom applications should have authorization to access data or perform tasks for them. This capability is provided by OAuth 2.0.

About Enterprise Applications

Enterprise applications are web applications that require App Gateway to integrate with Oracle Identity Cloud Service for authentication and authorization purposes.

Enterprise applications work similarly to confidential applications if you configure the Client Configuration and Resource Server Configurations section under OAuth Configuration tab.

To configure an enterprise application to work with App Gateway for authentication and authorization purposes you need to know the following information about your web application:

The web application's base URL. For example, if a known URL of your application is http://myapp.internal.example.com:3266/myapp/private/home, then the base URL is http://myapp.internal.example.com:3266.

The list of resources of your web application. For example, if your web application exposes the following URLs: functionalities A to Z in the following format /myapp/private/funcA to /myapp/private/funcZ, a home page /myapp/private/home, a logout URL /myapp/logout, an about page myapp/public/about, and an index page /myapp/index, then the list of all resources of your web application is:
- URLs from /myapp/private/funcA to /myapp/private/funcZ
- /myapp/private/home
- /myapp/logout
- /myapp/public/about
- /myapp/index

For each resource, define which resources require the user to be authenticated, which don't require user authentication, and which resource represents the log out action. Below are examples of authenticated and non-authenticated resources:
- Resources from /myapp/private/funcA to /myapp/private/funcZ, and /myapp/private/home require the user to be authenticated.
- /myapp/logout logs the user out.
- Both myapp/public/about and /myapp/index are public resources and don't require the user to be authenticated.

For each resource, define who can access which resource and which HTTP Method will be allowed or denied access. For example, you can define that all members of group Employees are allowed access to make GET and POST HTTP requests to resource /myapp/private/home, only members of group MyGroupA can access /myapp/private/funcA, and only users accessing from within network perimeter IntranetIPs can access resources from /myapp/private/funcB to /myapp/private/funcZ.

Identify URL patterns that apply to your list of resources. In the previous example, the URL pattern /myapp/private/.* matches all the application's functionality URLs and the home page URL. All these URLs may require the same kind of authentication.

About the Relationship Between Oracle Identity Cloud Service and Applications

In Oracle Identity Cloud Service, each custom application is represented by an application template. This configuration template is used to define the identity, access, and configuration information that Oracle Identity Cloud Service requires to communicate with the application.

When you purchase an Oracle application, an instance of the application is created in your identity domain and appears in the Oracle Cloud Services page automatically.

For a custom application, you must configure Oracle Identity Cloud Service so that it can communicate with the application. You use an application wizard to create a custom application. By doing so, in your identity domain, you add the information that Oracle Identity Cloud Service uses to communicate with the application. See Add Applications. Custom applications are shown in the Applications page.

You can use Oracle Identity Cloud Service to grant users access to applications in two ways:

Directly: Assigning users to the applications
Indirectly: Assigning groups to the applications. Any users who are members of the groups are granted access to the applications.

In addition to granting users and groups access to Oracle applications, you can grant users and groups access to entitlements within applications. For example, you use Oracle Identity Cloud Service to grant John Doe and Jane Doe access to Oracle Java Cloud Service. You want John Doe to have administrator privileges for Oracle Java Cloud Service, but Jane Doe to have only user privileges.

Each entitlement in an Oracle application is represented by an application role. So by assigning John Doe to the application administrator role of Oracle Java Cloud Service, he can access this Oracle Cloud service and he can function as an administrator within it.