Given Fischer’s vision in the mid-2000’s and our understanding that multi-tenancy would be the most secure, cost-effective way to offer a scalable, cloud-based identity we extended it to our entire product suite, which includes on premise deployments.Fischer constructed its multi-tenant architecture primarily to provide a mechanism to offer a 1-to-many Fischer to customer administrative model.  Fischer provides Managed Identity Services in the cloud.  We own the trademark for Managed Identity Services as well as “Identity-as-a-Service” as well as “IaaS”.  This is a result of Fischer’s vision in the mid-2000’s that the cloud would become the ultimate broker of identity-related security and essentially future-proofed our architecture long before analysts and the majority of consumers considered cloud based identity management as an option.  Now that cloud-based Identity Management is at the forefront of the security industry and has become the single most important concept that organizations are considering to not only help alleviate infrastructure related cost burdens, but also to leverage Identity, Governance and Security professionals that are often times hard to hire in house due to their high demand in the security market and the ever-changing landscape and the velocity associated with the salaries required to properly staff all the core elements of an Identity, Governance & Administration staff.  While some are able to accomplish the proper mix and to retain the necessary talent, many organizations struggle with it and the cloud is becoming a very attractive option for such entities.

It’s important to note that Fischer’s product suite works exactly the same on premise or in the cloud.  This should be seen as a strategic advantage to organizations because it offers a choice to start with an on premise solution and eventually migrate it to the cloud, or if executive management ever changes and the preference is to move the solution on premise, Fischer provides a seamless migration process (which we will discuss) that makes this process happen efficiently and seamless to the end users, IGA Administrators and functional units.  The software does not change, only the physical location where it runs.  This type of agility is extremely important when considering more than just the features of IGA as it is also important to consider business continuity.  Fischer’s import / export feature is a powerful feature to help with your disaster recovery scenarios as well, which we will also discuss further in detail during this course.

How does multi-tenancy work?

Multi-tenancy breaks down to a single installation of the Fischer Identity Suite which than in turn be leveraged to service N number of client organizations.  Each client organization is unique in the sense that it is 100% unaware of the next tenant that may be running within the same (single) installation of the Fischer Identity Suite.

Here is a visual that we can use to explain how multi-tenancy operates at the functional level:

As represented above, each avatar represents a single-tenant.  In the single tenant model, the “application” represented would be the identity application and the database would represent the data tier required to support the identity application.  Single-tenancy is 1-to-1 (one-to-one) in every sense of the definition.  A separate application tier, separate web tier and a separate data tier.

With Fischer’s multi-tenant approach, administration can be consolidated to a single instance of the Fischer Identity Suite, which means one administration console to manage N client organizations.  There are multiple flavors of installing Fischer’s infrastructure, but for the sake of discussion, explaining single-tenant versus multi-tenant is sufficient for you to get an understanding of how Fischer works.  Fischer installs in the multi-tenant context, every time. 

This does not stop you from running only a single tenant and then building out a separate infrastructure and running a completely separate single tenant, but again that is an advance concept and if you are interested it is best to work with Fischer’s Infrastructure Group.

The next section will walk you through what the initial installation looks like, and how you can configure your Fischer instance to begin building out your solution.

Change Org

The fact that you are seeing the “Change Org” icon signifies that there is at least one more client organization running on this instance of Fischer.  Remember that we support N instance, however this icon will only appear if there are more than just the master organization configured.  Note that when you log in for the first time, you will not see the “Change Org” icon if this is your first installation.  The only scenario where you may see this icon, and it is the first time you’ve logged in is if this is a replicated instance and all of the underlying client organizations were imported into this instance.  This is typically something you would see in a disaster recovery scenario or if you are moving your Fischer instance to a new physical location.

When you click the “Change Org” icon, you will be directed to a screen that looks similar to this:

What you will see on this screen is the available client organizations that you are privileged to see and select.  When you select a different organization, Fischer will refresh and the administrative context will convert to the org you’ve selected.  So what does that mean?  For example, here is a screenshot of a client organization’s “Systems” tab, depicting the target systems integration specifically to this tenant.

Now, let’s change to another client organization.

Click the “Change Org” icon and select a different org.  (Note that you can either select the radio button or then click the “Select” button to refresh your session into the selected client org or a shortcut is to simply double-click the radio button without clicking select).

:

Same “Systems” tab view but from the FIS client organization:

This should help you to make sure you are in the actual client organization you are expecting to be in.  It is a best practice to name each client organization differently so IGA Administrators can notice the distinction.  While the first organization had 4 Connected Systems integrated, the newly selected organization only has 2 (two).

You may be confused because if you look closely you’ll see the System Name of “IdmDatabase” and “IdentitySystem” are also integrated with the first client organization.  Note:  The “IdMDatabase” and “IdentitySystem” will always be present in every client organization for reasons that will be explained later.  You will notice that you are not able to delete either system from the client organization.  If you try to, the “Delete” option is disabled.  The software is functioning as designed and this is not a bug, so don’t panic.

Adding new Client Organizations and Client Org Administrators

Certain IGA Administrators will retain master privileges in the master organization as well as client organizations.  This is for the purposes of governing and providing oversight across all organizations running on a given instance of the product.  While the capability exists, it should be used sparingly.  It is very easy to simply provide master organization rights to each IGA Administrator, but this creates a security risk and is a bad practice to follow.  As you begin building out your administrative hierarchy there are many things to consider.  We will discuss what an administrative hierarchy should look like for your IGA Administration team in a later section of this course.  For now, we will focus on the mechanics of adding a new client organization, followed by assigning administrative rights to IGA Administrators.

First, let’s focus on creating a new client organization.  To add a new client organization, you must be authenticated as the master administrator or separate IGA Administrator that has been provided the privilege to create new client organizations.  The example below will use the master organization administrator account specified during the installation of the Fischer product.

Once authenticated, click on the “Configuration” tab, following by the “Organizations” tab.

The “Organizations” option is only available if you are authenticated and have an active session within the master organization.  If you don’t see the “Organizations” option in the Function Menu, you are either in a client organization or you do not have permissions for client org administration.

You should see the following if you have the proper permissions and are in the right place:

To add a new client organization, click the “Add” button and you will be presented with a form to complete to add a new client organization.  This next section will break down each portion of the presented user interface and provide context.

This is a snippet of the “Add Organization” screen.  We will show the remainder of the configuration options below. But let’s start with explaining what you are looking at:

Code (a.k.a “org codes”): 

This is a significant value as it will be used to delineate one client organization from the next for items such as the FQDN and ultimately the resolution of the distinct end user facing screens. 

Name: 

This is the name of client organization and is used for internal reference purposes.

The org "Code" and the "Name" cannot be changed once you create the new org. The only way to change this value would be with the assistance of highly trained database administrators. There should rarely be a case where these values need to be change other than for preferential reasons. There is no technical reason to change these values however they have vast significance to your back-end data structure once you introduce client organizations. IT IS ADVISED THAT YOU NEVER ATTEMPT TO CHANGE THESE VALUES IN THE DATABASE.

Display Name:

This is the value that will be displayed in the administration UI in the header.  For our example, the value of “Identity Mgt.” and “Next Generation IGA” that show up above the tabs in bolded, red text is the Display Name value set during org creation.  Note that you can change this value without affecting your solution.

 Description:

This value is there for IGA Administrators to provide a verbose description of the client organization if necessary.  It can also be changed at a later date and time if needed without affecting your solution.

The next portion to be completed while creating a new client organization is shown below:

Let’s walk through each of the properties shown in the screenshot above and discuss its significance:

Global Administrator E-mail Address:

This value is exact what the label states it is.  This global administrator email address will receive all notifications that are configured to be sent to this entity.

 Maximum Active Workflow Instances:

This property is a throttling mechanism put in place to allow for IGA Administrators to control resource allocation across multiple client organizations.  The number that is set here represents the maximum number of workflows (i.e. “automated processes”) that will be able to execute at run time.  Once this threshold is met, Fischer’s workflow queueing feature will queue all initiated workflows above this threshold and only allow them to be executed once there is room available below the maximum cap set here.  For example, if 1,000 workflows are executing, and then 10 more are initiated, those 10 will be queued up.  If 5 workflows finish and free up 5 additional spaces, Fischer’s queue will release 5 more workflows to execute and the other 5 will remain in a queued state until there is available threads to execute them.  This setting is used to help control computing resources (i.e. CPU, RAM, etc) to ensure that IGA Administrators, and Infrastructure personnel can control their multi-tenant platform.

 LDAP User BaseDN:

This property is used to determine where this specific client organization LDAP objects will be stored within the Identity System.  If you select the checkbox stating “Create OU(s) that does not exist, the Fischer product will automatically create the OU within the Identity [LDAP] System.  If you do not check this box, you will have to manually create the OU in the LDAP directory you specific during the installation of the product.  Make sure that if you decide to manually create it, that the DN matches what is typed in the input field or creating new Identities will not work.  We will now discuss the placement of Identities and the proper formation of the LDAP tree within your Identity System.

 

This next section deserves some special attention as it can be a little tricky.  Let’s explain the OU / Tree structure requirements for Fischer’s Identity System and how it all works.

Once you click IdentitySystem, you’ll need to locate the following property in the configuration (you may have to scroll):

So, if we compare the User Base DN value currently configured within the IdentitySystem configuration with the default listed in the “Create New Client Organization” screen, you’ll see the values are the same:  Here is that screenshot again (from the "Add client organization screen"):

So, this means that if you decide that you want all LDAP objects created in the IdentitySystem to reside in a unique OU, they be under this master branch.  For example:

If you wanted ou=NewOrg,ou=identities,dc=coo,dc=fisc,dc=int the product will allow you to continue creating your new client organization.

However if you changed the LDAP User BaseDN to ou=identities,ou=NewOrg,dc=coo,dc=fisc,dc=int IT WILL NOT WORK because ou=NewOrg is above the root suffix of ou=identities,dc=coo,dc=fisc,dc=int

Administrating the File System Components of a Client Organization

Fischer’s infrastructure course will get you more into the specifics of each of the working components of the different tiers associated with a properly functioning instance.  For this course, we will focus on administrating the file system within the context of the client organization.  There are a few manual steps required in the current version in order to ensure your client organization URLs properly resolve.

Refer to the “About” screen shot from above and let’s remember that Fischer leverages Apache Tomcat for web application services and to execute our source code.  Tomcat is also the location within the file system where the files must exists in order to be rendered at the presentation layer (i.e. the browser).

The root location where the files reside that render to the browser when a client organization URL is typed into the browser are here:

It is important to note that a customer can place the files anywhere they desire. The path's represented below are for a window platform and all required components are installed in the Root C:\ of the selected storage component.

This screenshot depicts the \webapps folder within Apache Tomcat which is used for rendering pages to the browser amongst other key functions that will be discussed in the Infrastructure Course.  The location of the actual web files used to render client organization end user facing interfaces is here:

You will see a File folder called “fis”, which was what the “Self-Service UI Root” property listed above was defined to be.  As noted previously, this client organization property is editable, so if we make a change to the fis client organization configuration, specifically if we change the Self-Service UI Root to “2” instead of “fis” as seen here…

AND we forget to edit the file system which currently is configured like this:

The result when attempting to access the new URL of “…/self-service/2/…” will be:

Then, we remember that the Self-Service UI Root was not updated in the file system so we go ahead and make that change in the file system as shown here:

And now we attempt to access the new client organization’s URL   SUCCESS!!!

Ensuring Root UI value in the administrative user interface matches that value in the file system is important to ensure that each client organization's self-service interface can be rendered successfully.

Note you do not have to reboot your web application server to affect the change to the absolute path for the Self-Service UI Root value.  If you change it in Fischer’s administration UI and you make the subsequent [required] change to the Apache Tomcat file system, your URL will resolve correctly

Defining Mulit-Tenant Administration

We now need to define which IGA Administrators will be assigned to the newly created client organization.  Fischer has provided extensibility and empowerment for IGA Administrators and organizations to govern their client organization’s however they need to.  To this end, Master Administrators can come from the primary Master Organization (installed with the product) or organizations are able to select identities from other organizations to become a client organization administrator for any organization.  It is important that you consult with your Information Security team before determining the proper personnel to assign and to ensure that you are following your organization’s Information Security and/or regulatory guidelines prior to assigning a master administrator to any client organization.  For the sake of this course, the steps to add a master client organization administrator are as follows:

Click “Add” to see the list of available administrators

During the initial definition of who is able to be assigned master administration rights over a client organization you will only see identities from the initial [default] master organization.  Furthermore those users must be a member of the “Master Administrators” User Group.  We will discuss how to add members to this group later on in this course.  After clicking “Add”, we will see:

The first identity is the global master administrator defined during the installation of the product, the second user is an identity within the [default] master organization that was added as a member to the “Master Administrators” User Group.  We will select “Dan Dagnall” as the master administrator of the client organization once we walk through all the steps.

Remember that any identity that you desire to be able to be a client organization master administrator must be a member of the “Master Administrators” User Group

Now, let’s put it all together and create a new client organization:

You will notice that your newly created client organization will be "Disabled" upon creation. This is the default setting within the product. If you do not see the organization you are looking for, you will want to make sure it is enabled. The final step after you've created an org is to "Enable" it.

To enable the client organization, you will access the organization and enable it:

Note you have one final option when creating a new client organization. By default, all out of the box PSA policies will be added to the new client organization. By checking the box you can also clone custom PSA policies you may have created. Note the custom policies would come from the Master Org.