AD Delegated Authentication is a way to synchronise user passwords between an on-premises Microsoft Active Directory enterprise directory structure and Oracle Identity Cloud Service (IDCS). Users can use their AD passwords to sign in to IDCS to access resources and applications protected by Oracle IDCS. We will use Office365 as one of the target applications. Oracle IDCS can provision user into Office365 and keep users synchronised.
The following diagram 1 depicts the scenario:
Diagram 1: Logical architecture of scenario
Following are the steps that are taken in order to configure and test the scenario:
- Step 1: Create an AD Bridge to have users and groups from Active Directory copied and synchronised in Oracle IDCS. The AD domain is called idcsdemos.com. This process is described in great details in the following URI – https://docs.oracle.com/en/cloud/paas/identity-cloud/uaids/managing-bridges-oracle-identity-cloud-service1.html
This is depicted in the diagram 2 below:
Diagram 2: AD Bridge defined in IDCS
- Step 2: The following diagrams 3 and 4 depicts the users and groups that are defined in the AD domain idcsdemos.com, respectively:
Diagram 3: Employees group in IDCSGroups in idcsdemos.com domain
Diagram 4: Users in IDCSUsers in idcsdemos.com domain
- Step 3: Configure the AD Bridge in IDCS selecting IDCSGroups and IDCSUsers to copy entries from these branches. This is depicted in diagram 5 and diagram 6 below:
Diagram 5: AD Users and Groups to be copied and synchronised
Diagram 6: Attributes Mapping
- Step 4: Set the import frequency and Authentication settings to enable local authentication for delegated authentication. This is depicted in diagram 7 below:
Diagram 7: Enabling Local Authentication
- Step 5: Activate Delegated Authentication from Delegated Authentication tab under Security settings. This is depicted in the diagram 8 below:
Diagram 8: Activating delegated authentication
- Step 6: Add an application Office365 from the application catalog in IDCS and configure it to provision users and synchronise users into Office365. This is depicted in the diagram 9 below:
Diagram 9: Adding and configuring Office365 application in IDCS
- Step 7: Add a new user called Steve Stroud enrolling him in the ‘Employees’ group and assigning him an email sstroud@idcsdemos.com. This is depicted in the diagrams 10, 11, 12 and 13 below:
Diagram 10: Creating Steve Stroud in AD
Diagram 11: Steve Stroud created under IDCSUsers
Diagram 12: Assignment of email address
Diagram 13: Assignment of group – Employees
Diagram 14: Creation of user Steve Stroud in IDCS
- Step 9: Steve Stroud assignment of Employees group in IDCS is because he is in Employees group in AD. The Employees group is associated with Office365 application in IDCS. Therefore, Steve is associated and provisioned in Office365. This is depicted in diagram 15, 16, 17, 18 and 19 respectively:
Diagram 15: Steve Stroud is enrolled in Employees group
Diagram 16: Employees group access to Office365
Diagram 17: Steve is associated with Office365 in IDCS
Diagram 18: Admin logging in to check Steve Stroud provisioning into Office365
Diagram 19: Steve Stroud provisioned into Office365
- Step 10: Finally, Steve Stroud wants to access Office365 account over the internet by visiting http://www.office.com website. In the login challenge Steve puts his Enterprise domain email userid. This is depicted in the diagram 20 below:
Diagram 20: Steve Stroud using his enterprise userid for logging into office.com
- Step 11: Office365 being a service provider directs the login to Oracle IDCS for authentication. Steve supplies his Corporate AD password to Oracle IDCS login dialog and gets into Office365 account. Oracle IDCS delegates authentication to Active Directory to authenticate Steve. This is depicted in the diagram 21 and diagram 22 below:
Diagram 21: Steve Stroud has been directed to Oracle IDCS for authentication
Diagram 22: Steve gets into Office365 application
RedThunder.Blog 