The identity domain is a construct for managing certain features of Oracle Cloud. Many features of Oracle Cloud are managed within and between domains.
Users and Roles
Users and roles exist within the identity domain. Users with administrative roles manage local cloud identities and their rights. Access management within the domain depends upon users and roles.
- Standard users: These users add user accounts, import a batch of user accounts, assign roles to users, modify user accounts, reset passwords, and remove user accounts.
- SFTP users: These secure FTP (SFTP) users set passwords for their accounts, which are used to sign in to an SFTP server to perform FTP operations related to your Oracle Cloud service.
- Predefined roles: View a list of all the predefined roles created by Oracle Cloud and link to a list of users assigned to the role that you select.
- Custom roles: View, add, and remove roles that you created for customized access to your Oracle Cloud services.
- Account administrator: The account administrator role is at the service instance level. It gives a user several responsibilities to manage one or more Oracle Cloud services. As account administrator, you’re responsible for managing an Oracle Cloud account through the cloud user Interface (UI) and you have business oversight responsibilities over service instances across one or more identity domains. You can nominate service administrators and identity domain administrators for services that you buy. You can view metrics for individual service instances.
Note:An account administrator doesn't have to be a user in SIM.
- Identity domain administrator: As an identity domain administrator, you manage your own users and their roles. Your view is limited to the users and roles in the identity domains that you’ve been assigned to manage. You see all the roles at the domain and service levels. An identity domain administrator is a super administrator for an identity domain and for all the services within the domain. An identity domain administrator can delegate other identity domain administrators as well as manage roles assigned to service administrators. As an identity administrator you perform administrative responsibilities for the whole identity domain.
- Service administrator: As a service administrator, your view is limited to the users and roles for the services that you’re assigned to manage. You see the roles only at the service level. In addition, you’re limited to mostly search, view, and read-only functions. For example, you can’t create roles or user accounts, but you can assign an existing role to an existing user account. A service administrator is a super administrator for a given service instance. As a service administrator, you can assign more service administrators to roles as well as manage other roles associated with the service. However, you can’t create users or roles.
- Customer service representative administrator: As a customer service representatives administrator, you have administrative responsibilities for operations that perform in deployed cloud services. You’re the equivalent of an identity domain administrator for all of a customer's identity domain.
Relationship Between Identity Domains, and Administrative and Delegated Roles
The following architectural illustration shows the relationship between identity domains, and administrative and delegated roles.
In this illustration, the account administrator (Acme Buyer) is a user defined in the Oracle.com SSO, and is identified within the Oracle Store — global single instance. This user represents a buyer for a customer, and is responsible for managing an Oracle Public Cloud account through the cloud UI. In addition, the account administrator has business oversight responsibilities over service instances across one or more identity domains.
For this example, Acme Buyer is responsible for the Oracle Public Cloud identity domain. Within this identity domain, the Acme Buyer nominated both an identity domain administrator (ID domain administrator) and service administrators (Identity Admin, JCS-SX Admin, Schema Cloud Service Admin, and BI Cloud Service Admin) to manage services that the account administrator buys.
- Role, user, and security management capabilities, which are associated with identity management (IDM) roles.
- Java administrator capabilities, which correspond with Oracle Java Cloud Service roles.
- User, developer, and administrator capabilities, which are linked to roles associated with schema service roles.
- Hierarchical role operations associated with Oracle Business Intelligence (BI) Cloud Service.
Because the ID domain administrator is the super administrator both for the OPC-IDM identity domain and for the services within the domain, this user can delegate service administrators (for this example, Identity Admin, JCS-SX Admin, Schema Cloud Service Admin, and BI Cloud Service Admin) and manage associated roles (including IDM, Oracle Java Cloud Service, Schema Cloud Service, and Oracle Business Intelligence (BI) Cloud Service roles).
The customer service representative administrator (CSR Admin) has administrative responsibilities for deployed cloud services, and has identity domain administrator privileges for all identity domains. For this example, the CSR Admin is a member of the OPC operations and support staff role. Because of this membership, the user has administrative privileges over three identity domains: OPC-IDM, CSR, and Acme2.
Within the identity domain, you can view your user information, change your password, and change your password challenge questions.
Within the identity domain, you can add, modify, or delete contacts who would receive service notification email about planned maintenance, service outages, and so on. The Contacts tab is available only if the user is a service administrator for any services. Identity domain administrators (who aren’t service administrators) won’t be able to perform this functionality.
Client and API Communication Using OAuth 2.0
Oracle Cloud uses the open standard OAuth 2.0 authorization protocol to communicate with internal and external services.
The Oracle Cloud identity infrastructure provides an OAuth token service, which grants secure access to the Representational State Transfer (REST) endpoints of cloud services by other cloud services and by other clients. For example, a client application deployed to Oracle Java Cloud Service—SaaS Extension might need to access the APIs of a SaaS application, such as a human capital management (HCM) application. OAuth provides a way to allow access by known clients, while protecting the APIs against unauthorized access.
User Integration Using Single Sign-On with SAML 2.0
Oracle Cloud uses the open standard Security Markup Language (SAML), version 2.0 to implement SSO between internal and external users. The OAuth service in Oracle Cloud provides service-to-service authorization, and service-to-service identity propagation.
SSO lets you provide access to one domain to users who have been authenticated to a different domain, or to an on-premises identity store. For example, you might want your users to log in to Oracle Cloud by using a local directory, such as Microsoft Active Directory Federation Services (ADFS) or Oracle Unified Directory. The SSO service is built upon the federation capability of the identity infrastructure. SSO uses the industry standard SAML, version 2.0 to exchange information between an identity provider and a service provider.
External Identities and Single Sign-On
- Non-federated:Stored on one local identity management system. These user identities are associated only with Oracle Cloud. As a result, they’re known only to Oracle Cloud.
- Federated: Stored across multiple distinct identity management systems, and are coming from different domains.
Federated users receive their identities from their administrator. These identities may be known to Oracle Cloud through a Lightweight Directory Access Protocol (LDAP) export to SIM. However, these users can’t log in to Oracle Cloud directly. Instead, they’re redirected to their federated site for login.
Then, SSO gets a SAML assertion from the identity provider. The SAML assertion contains user information from the identity provider. SSO parses the SAML assertion and asserts the identity to the identity domain.