OCI Identity and Access Management Integration

Welcome to the demo of OCI identity and access management integration in student financial aid within Oracle's student cloud.

SFA integration with OCI identity and access management enables enterprise grade, identity and access management capabilities with new features and security enhancements routinely delivered by Oracle.

For SFA customers, this integration allows you to self-service management of users, groups, security and many other settings and configurations.

SFA specific configurations will remain within the SFA application, allowing SFA to deliver changes as needed, and to our customers to support separation of responsibilities where applicable.

This demo shows you how integrating with OCI identity and access management enhances your business.

To start, please access the OCI cloud console via cloud.oracle.com.

To login use the OCI cloud account that you originally used to provision your SFA environments.

Integration between your SFA environments and OCI identity and access management will require some initial set-up.

Within the OCI cloud console if you select the menu in the top left and then Identity and Security then Policies.

You can select the option to create a new policy.

Please refer to the OCI identity and access management documentation on policies, and also the SFA release notes on some different options around the policy required for SFA to interact with your identity domain.

It's important to note that any changes to this could impact the integration and functionality between your SFA environments and OCI identity and Access Management in the future, and of course, deleting the policy will cause that integration to break. For customers provisioned before the release of 25A an additional step will be needed to enable integration between SFA and OCI Identity and Access Management.

Within the OCI cloud account that you used to originally provision your SFA services you need to select or create a new identity domain for use by SFA.

After you have logged into the OCI cloud console using the OCI cloud account that you previously created select the menu and go to identity and security.

Select domains, you'll be presented with a list of current domains.

You can either select to use an existing domain or create a new one.

Once done, and you've either selected or created a new identity domain for use, the identity domain OCID an example displayed here, and the domain url example displayed here need to be submitted to the SFA team.

This identity domain needs to be used for all of your SFA environments. So this information is only required to be submitted the first time you want to move one of your environments from legacy to hybrid mode.

For customers, provisioned before 25A, an additional setting that needs to be verified within the identity domain to be used with the SFA integration is under settings.

Domain settings, Configure client access must be configured for SFA to integrate correctly with your identity domain.

It's also critical to verify the primary email address required is selected.

Changing this in the future, or the client access setting will cause integration between your SFA environments and OCI identity and access management to break.

When an environment is moved from legacy to hybrid mode, or for an environment provisioned for new customers after the 25A release, SFA creates two Oracle cloud service apps within the OCI identity domain selected for the integration.

One app is used to integrate the admin ui and apis, while the other for portal integration.

The admin ui app's naming convention includes the environment name and underscore admin, while the portal includes the environment name and underscore portal.

In hybrid mode, the legacy endpoints will still be enabled for authentication.

Here is an example using one of our qa environments for the portal local login.

Again, using one of our qa environments that has been configured for single sign-on with a third party identity provider, it redirects to the login.

Additionally, the new end points for OCI IAM integration will work.

Here is an example. In hybrid mode, you will notice a few differences in the admin ui.

First under administration roles management.

You'll notice this group mappings tab.

It displays a list of groups that is synchronized from the OCI identity domain that's integrated with your SFA environments.

By default, a few groups will be created.

All domain users Domain administrators are created by OCI.

The admin group and sys admin group are created by SFA.

And then you'll notice that other groups here that are created by SFA users or OCI identity admin can create groups within the OCI cloud console.

All of those groups will be displayed here.

So make sure to take care, when doing the group mapping, that you're selecting the group that you intended to select.

It's recommended to adopt a naming standard for groups that matches the requirements of your organization.

When switching from legacy to hybrid mode, all of the roles that were set up still be here and exist and work.

They will not be mapped by default to any groups, so you can come in here and choose which groups to map to.

I can map an existing rule to a group. So, as an example, advisement read-only.

I can select the box for demo test, and it saved, and that will update now, this existing rule is mapped to a group in OCI.

I can also create a new group here and assign it to an existing rule.

If I add this group, it'll create a group in OCI and then re-fresh and synchronize the list of groups live and then I can select that group for use here.

So I hit save.

The group mappings has refreshed, and now I see demo-test3, so I can again take advisement read-only.

Select this new group and hit save, and it is mapped accordingly.

I can create a new role.

Let's call it demo3. The role name will be Demo Test 3.

I can choose the groups that I want to be associated to this.

I'll just select Demo Test 3 for now.

Then I can select permissions that I want to associate to this new role and document permissions.

I'll just stick with this one general permission for now and save.

Now you'll see the new role is created mapped to the group that I selected with the permissions.

You'll notice this sync groups button here I could select this to do an on demand, a synchronization of the groups that exists in the OCI Identity domain configured for use with the SFA environment, and it would refresh this list and populate any changes. That same synchronization happens every night by default and then also upon accessing the role management screen.

You'll also notice a difference on the user management page.

You'll see, under user type, the sources of the users that logged in notice, internal for legacy local login accounts for environments that were integrated with third party identity provider.

Those show up as external SAML.

Those are both considered the legacy authentication methods at this point.

Any user that logs in through the new OCI identity integration will show up as external OCI SAML.

You'll notice, an example of my test account here I've logged in through the legacy sso, SAML endpoint before, and also with the new OCI integration.

So this exists for use by customers to track the source of logins and user accounts.

In hybrid mode, you'll also notice in differences in the admin experience in the portal.

First off under settings role permissions.

You'll notice this group section.

This group section is automatically synchronized from the OCI identity domain integrated with your SFA environment.

By default, no groups will be associated with any of the roles that existed.

But you're able to take a role, and associate, a group to that.

As an example, I'll map Default Student to Portal Group 1 and save.

Now this role is mapped to that group.

I could also map by that role to a new group.

Group name demo-test4.

Group description Demo Test 4, and then hitting okay.

This group is created in the OCI identity domain that's integrated with the environment, and then the group's list is refreshed, demo-test4.

So I can now select that hit save, and this existing role is now mapped to this new group.

So now I can go into the OCI cloud console and I could add members to that group, and they would be part of this role in the corresponding permissions upon next login.

On the user management tab, you'll also notice a couple differences.

The legacy users that logged in, you'll notice that you're able to edit those users and make changes.

For users that have logged in through the new OCI identity integration you are not able to edit those users.

Any changes need to be made within the OCI cloud console for the user.

If you hover over the user as you can see here, you'll get a little pop up display of the last login time for the user, and it also notes external system link, and it says OCI SAML.

User group and other settings management is done within the OCI cloud console.

You can access the OCI cloud console by going the cloud.oracle.com logging in with the cloud account that you used to originally provision your SFA services under.

And then the identity domain that you previously selected for use with the SFA and OCI identity and access management integration.

Once logged in, you can access the identity domain and select users.

Here you'll see a list of users that exist in the identity domain and can manage those users accordingly.

Here's an example of a student test account.

You notice you can select, edit user, modify attributes of the user, including the student ID, which is a custom attribute that SFA adds to your identity domain during initial set-up of the integration.

This is used to house the student ID values for students and guest accounts.

From the user's view you can also create new users by selecting the create user button, populating first name, last name, email and then selecting any desired groups.

Groups can be selected after creation of the user account.

In the user's view, selecting a user, you can also manage group membership.

Any groups that exist within the identity domain can be selected and the user will be added to those groups.

You'll notice the demo groups that we created earlier in the admin ui and portal are listed here.

I can add this student test account to demo-test4, assign user.

Now, this user is a member of this group.

Next time they log into the portal, they would give them permissions associated to the role that that group is mapped to.

Additionally, I can remove the user from a group.

Under the groups menu, you'll see all the groups that exist in the identity domain, including ones created via OCI - domain administrators, all domain users.

Those created by SFA, by default, admin, sysadmin and any other groups that you have created, either in the OCI cloud console or through the admin ui or the portal.

You can manage these groups here, assign users to the groups, remove users, edit group names, etc.

When accessing the admin ui and portal, any changes here will be synchronized.

SFA integration within Oracle identity and access management allows for self-service configuration of third party identity providers within the cloud console.

Select security, Identity providers.

You can configure a new identity provider.

Here, you can select, add idp and then add SAML idp.

At this time, SFA is only supporting SAML identity providers.

I'm just going to cancel out of this wizard and take a look of one that we have already configured.

You'll notice the information is displayed here.

I can edit the properties of this, name, description, custom icon. I can upload new metadata from the external idp.

If I need to make any changes, that can also change any other mappings that are needed here.

Now for integration with SFA, the requested name ID format can be left as none, and the idp user attribute in the assertion SAML assertion name ID is mapped to use username.

One other very important item is the configuration of just in time provisioning.

By default this will be turned off when you create an external idp.

You can turn this on and then select to have the user account be created if it doesn't exist and then also have attributes updated if the account does exist.

Then you can map attributes that would come from your external identity provider to the corresponding attributes within the identity domain.

It's important to note that SFA has a set of attributes that are required.

We configure those as part of the configuration between SFA and your OCI identity Domain but you can map your external attributes to those attributes here.

You can also assign a group mappings, through the assertion from your third party identity provider.

You can do implicit group membership or explicit group membership, you can also do default group memberships if you wanted to a few other options exist here as well. If you're using an external identity provider, and you choose not to use just in time provisioning OCI requires that the account for a federated user still exists in the identity domain, with the type of federation set to true.

So you would be responsible for creating those user accounts within the identity domain manually or through some other automation if this was not enabled.

Once you've configured an external identity provider and activated it, you need to add it to an identity provider policy.

There is a default policy here.

You can create additional policies we will take a look at the default one, and the default rule here select edit idp rule.

The assigned identity providers for this default rule by default will say username and password. You can add the external idp that you've listed here and then also incorporates some conditions around it.

It's important to note that if using just in time provisioning and you want to user to log into the external idp and the user account has not been created, you cannot select username password here.

You must have the redirect from SFA to the identity domain that is configured for integration and then automatic redirect to this external identity provider.

After moving from hybrid to migrated mode, all of the legacy and points will automatically redirect to the new SFA and OCI Identity and access management integrated endpoints.

As an example, any logins to the local portal login will automatically redirect to the new OCI Identity and Access Management endpoint.

Similarly, for the admin ui, anyone that may have configured sso SAML integration that will now redirect as well to the new endpoint.

Additionally, the new end points will work and redirect as expected.

After moving from hybrid to migrated mode, you'll notice a few changes in the admin ui.

Under administration, user management, all users are now read-only.

Any of the users from the legacy authentication endpoints can no longer login, but the records still exist, and users from the SFA and OCI identity and access management integration, which are listed as external OCI SAML as the user type.

Those users are managed in the OCI cloud console.

Some information is viewable here, but again, any changes need to be made within the OCI cloud console.

Under administration roles management.

The same experience that was introduced in hybrid mode still exists.

Here you'll see the group mappings synchronized from the OCI identity domain that supports the integration with SFA.

After moving from hybrid to migrated mode, you'll see some differences in the portal as well.

Selecting the menu and go into settings.

You'll notice that the groups option related to roles is here, as introduced in hybrid mode, but other options as well have been removed or changed.

You'll notice that the email communication preference section previously available is no longer here.

All notifications will now come from the OCI identity and access management integration and are managed within the OCI cloud console, within the identity domain selected for integration with SFA, under the notifications options.

Also the guest authentication mode has been introduced.

This replaces the previous guest and student authentication mode.

This option gives you the capability to decide whether or not OCI identity and access management should be the identity provider for your guest users, or if you would like to use an external idp to manage the guest users.

By default portal will use the OCI identity and access management integration for guest user, authentication and authorization.

By selecting this option and saving it, it will disable the use of OCI identity and access management.

You will be responsible for populating the required user within the OCI identity domain.

As noted earlier, OCI identity domains require a federated users to exist within the identity domain and be set to type federated in order to be able to use the identity domain for authentication authorization.

Please refer to just in time provisioning mentioned previously in the demo.

Also just in time provisioning within the OCI identity and access management documentation and the SFA release notes.

When an environment is moved from legacy to hybrid or for an environment provisioned for new customers after the 25A release, SFA will support v2 api endpoints for some apis with a new authentication and authorization scheme.

Please see the release notes for further details.

Access to the apis will require an oauth token issued from a confidential application you create within the OCI identity domain used for the SFA integration.

Please see the OCI identity and access management documentation and the SFA release notes for more detail.

The application you create will utilize the scopes on the Oracle cloud services admin app created for the SFA environment you want to interact with to issue the token.

An example here is the admin app created for one SFA environment.

On the OAuth configuration, you'll notice the scopes that are present.

After you have created and activated the confidential application to use to retrieve tokens, you can view and manage the application from within the OCI cloud console.

Within the identity domain. Under integrated applications.

Under OAuth configuration, you'll be able to view and modify the configuration as needed.

To make any changes select edit OAuth configuration and scroll down.

You'll find that you need to manage the assigned resources underneath the resources section.

It's best to leave the resources empty when not using the application to issue tokens.

When you do need to issue a token, it's best to only add the scopes that you need to use for a given activity.

As an example, I can expand the scopes associated to this test environment, and I can select the vug admin scope for that specific environment only and select add and then save changes.

Now, when I request a token specifying that scope, I'll be able to interact with the corresponding SFA environment, as needed, without any unneeded permissions.

It's also important to note on this page you can regenerate the client secret.

It is a good practice to regenerate this and also restrict who has access to this page and the capability to view and regenerate.

When you need to interact with an SFA environment via api, and after you updated the scopes listed in the resources on the confidential app, after you created and after you have noted the client ID and secret and base 64 encoded that value, you are then ready to make the api call to retrieve a token.

Here you see a curl command basic auth, including the base 64 encoded value of the client ID and secret of the confidential app that I created.

The post command will go against the identity domain used for the integration with the SFA environments at the OAuth v1 token endpoint.

The grant type is client credential, which matches the configuration of the confidential app and the scope, matches the scope of the environment that I want to interact with.

I can issue this command and the value returns the bearer token for use in an api call against the SFA environment that I need to interact with.

I can then take the bearer token, add it to a curl command, noting authorization bearer, and then the returned token, and issue an api call against the corresponding SFA environment.

The token is validated by SFA, the scope verified and the process allowed to complete.

SFA integration with Oracle identity and access management offers many other capabilities and features that you can leverage.

Some of those are found under the security menu option.

I ask that you please refer to the OCI identity and access management documentation, and also the SFA release notes for more information on these features and capabilities.

But you'll notice capabilities such as adaptive security, sign on policies, network perimeter management, multi-factor authentication, etc. are available here, can be configured and used by your organization.

Some of the other capabilities can be found under settings.

You'll find password policy and also session settings here for duration and idle timeout.

Other capabilities exist here and I invite you again to take a look at the documentation and see what can match your organization.

Other capabilities, such as branding, so the default Oracle identity and access management sign in page can be changed here.

And then very important to know that notifications are enabled by default.

Notifications are enabled and sent out to end users and administrators.

You can see, it's pretty long list here.

So any new user account that gets created gets a welcome email.

Any updates to it will activate another email being sent.

So during the hybrid phase, it is important to come in and disable any of these that you don't want.

And also customize the email templates as well to meet your organization's requirements.