Benefits of Connector Server

Oracle provides a component called "Connector Server". It has lots of benefits like

• Most of the processing related to connectors will be done in a separate JVM which can provide better performance for UI, Schedule Job, Event Handles etc.
  
• If we are having performance issues with the connector related transactions, it's very easy to add more nodes of Connector Servers as compare to adding new node of OIM and also reduces the work of patching/upgrade.
  
• If connector servers are used in a proper way then it can be used to build a better security architecture. If multiple applications are in a different network zone than OIM then place connector server in that zone. In this case only one firewall will be opened between both the zones i.e. OIM & Connector Server instead of opening multiple firewall i.e. one for each application.
  
• If any application is very critical or does heavy processing (multiple APIs call for single operation, requires to run full recon multiple times in a day), then it is easy to have dedicated/separate Connector Server(s) for that application only.

There are few cons of implementing Connector Server which can be discussed in a separate thread. :)

Some Sample Questions

 Some More Sample Questions:

• What happens to existing requests when approver leaves the company of gets terminated? What are the possible solutions (except escalation process) to provide better experience to end users?
• How can we trigger Java code between two stages of a Human Task?
• What configuration is needed if we need to send 5 reminders in an approval workflow?
• How can we send First Reminder on 3rd Day, 2nd Reminder on 8th Day and 3rd Reminder on 21st Day from the Request Creation Date?
• How can we implement RBACK? What components are required for RBACK?
• One role is configured to give access to two entitlements into two different applications (one entitlement in each application). We need to notify Requester and Beneficiary in a single email once the entitlements are provisioned successfully. Email must include basic request details -  Request Login, Role Name, Role Description etc.
• There's a requirement to integrate IAM/OIM with a cloud application which requires internet connectivity. What design approach should we follow to complete this integration?
• One role provided access to THREE different applications. There's a requirement to send a consolidated email to the beneficiary omce accounts are created in all the three applications, what would be the possible design options?
• In RBAC, request gets completed once the role is assigned but account(s) is/are provisioned through the OOTB schedule job. If there's some error while provisioning the application(s), request status remains same i.e. "Request Completed" which creates lots of confusion for end users. How can we make this process better?
• What is ICF Framework & How it works?
• What are the benefits of Connector Server?

Role Based Access Control vs Attribute Based Access Control

You might have implemented or currently implementing RBAC i.e. Role Based Access Control but you should also know about ABAC (Attribute Based Access Control) as ABAC is more advanced than RBAC. I have tried to explain both the access controls here, I hope this will help:

RBAC

RBAC stands for Role Based Access Control. In RBAC, access controls are defined based on the groups/roles a user is having. It simplifies the administration of access controls for large number of users. It’s the best model for cross-grained access control. 

Example:

• HR Administrators will get Read and Write permissions on HR Module of SAP
• IAM Role Administrators can create, update & delete any role in IAM System

 Pros:

• Simplifies the management of entitlements
• Usability: complex names of entitlements can be displayed with simple names of roles
• Efficiency: improves the efficiency by providing access into various system with a single role
• Security: it assigns only those permissions to the end user which are required to perform that business function
• Easy to implement as compare to other Access Control models
• Permissions are assigned to roles rather than to users
• Reduces the no of requests as requests will be raised for roles rather than for each permission

Cons:

• Dynamic SOD implementation is not possible
• Limited scope of scalability. After a certain limit, it becomes difficult to scale this model
• Doesn’t provide fine grained access control
• Access control definition is predefined
• Need extra efforts to manage life-cycle of roles

 

ABAC

ABAC stands for Attribute Based Access Control. ABAC provides the access based on attributes associated with user or application/system. This is the advance version of RBAC where we can achieve Fine-Grained access control. In this model, authorization policies are defined based on the context, user attributes, application attributes.

Example:

• Children with < 12 years of age will not get access to Movie A & Movie B
• Certain application can only be accessed by end users during work hours and from office

 Pros:

• Can be used to achieve Fine-Grained access control which is the need of today’s security system
• Scalable
• Can be used with existing Access Control models like RBAC
• Dynamic Segregation of Duties

Cons:

• Complex to analyze
• Possibility of attribute explosion

Disclaimer

All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information