Planning Analytics

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

Coming in late to this thread but we use the ClientProperties rule method to Add user based on their AD ID and match their domain.  When the click on Architect/Persectives it does the UserID@UserDomain match.  If a person cannot logon to a company machine then they wont be able to get to a TM1 system as when AD ids are disabled etc.

Not sure if this helps but it does keep it simple and still has a high level of security.

Shahhere

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

Thanks for the reply Shahhere. We do something similar currently for the on-premises models currently running.

There is also the IsDisabled flag which could be set.

I think the main issue here still is the fact that the entire domain is federated which is likely to impact other users in other areas.

The next step I guess would be to assess how many and what systems etc. would be impacted before deciding which authentication method to choose.

Coming in late to this thread but we use the ClientProperties rule method to Add user based on their AD ID and match their domain.  When the click on Architect/Persectives it does the UserID@UserDomain match.  If a person cannot logon to a company machine then they wont be able to get to a TM1 system as when AD ids are disabled etc.

Not sure if this helps but it does keep it simple and still has a high level of security.

Shahhere

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

I haven't done the AD integration in over a decade but does Federated mean in your application?

Shahhere

Thanks for the reply Shahhere. We do something similar currently for the on-premises models currently running.

There is also the IsDisabled flag which could be set.

I think the main issue here still is the fact that the entire domain is federated which is likely to impact other users in other areas.

The next step I guess would be to assess how many and what systems etc. would be impacted before deciding which authentication method to choose.

Coming in late to this thread but we use the ClientProperties rule method to Add user based on their AD ID and match their domain.  When the click on Architect/Persectives it does the UserID@UserDomain match.  If a person cannot logon to a company machine then they wont be able to get to a TM1 system as when AD ids are disabled etc.

Not sure if this helps but it does keep it simple and still has a high level of security.

Shahhere

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

Hi,
We have our IBM ids federated, but not the whole domain.  Each time a user wants access to PAoC we open a support ticket and add them to our federation.  After they are added, only then do we add them as users to PAoC. 

I haven't done the AD integration in over a decade but does Federated mean in your application?

Shahhere

Thanks for the reply Shahhere. We do something similar currently for the on-premises models currently running.

There is also the IsDisabled flag which could be set.

I think the main issue here still is the fact that the entire domain is federated which is likely to impact other users in other areas.

The next step I guess would be to assess how many and what systems etc. would be impacted before deciding which authentication method to choose.

Coming in late to this thread but we use the ClientProperties rule method to Add user based on their AD ID and match their domain.  When the click on Architect/Persectives it does the UserID@UserDomain match.  If a person cannot logon to a company machine then they wont be able to get to a TM1 system as when AD ids are disabled etc.

Not sure if this helps but it does keep it simple and still has a high level of security.

Shahhere

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

HI Scott,

Thank you for the feedback. 

As far as I understood from IBM they join the entire domain to federate the client's users on their corporate IDs.

Are your users using SSO when logging in or an IBM ID (username) and password?

Hi,
We have our IBM ids federated, but not the whole domain.  Each time a user wants access to PAoC we open a support ticket and add them to our federation.  After they are added, only then do we add them as users to PAoC. 

I haven't done the AD integration in over a decade but does Federated mean in your application?

Shahhere

Thanks for the reply Shahhere. We do something similar currently for the on-premises models currently running.

There is also the IsDisabled flag which could be set.

I think the main issue here still is the fact that the entire domain is federated which is likely to impact other users in other areas.

The next step I guess would be to assess how many and what systems etc. would be impacted before deciding which authentication method to choose.

Coming in late to this thread but we use the ClientProperties rule method to Add user based on their AD ID and match their domain.  When the click on Architect/Persectives it does the UserID@UserDomain match.  If a person cannot logon to a company machine then they wont be able to get to a TM1 system as when AD ids are disabled etc.

Not sure if this helps but it does keep it simple and still has a high level of security.

Shahhere

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!

My previous company had federated logins with IBM ID and Azure AD. When we set it up, IBM allowed user by user federation at that point in time so we had to request through the support tickets same as Scott. I think they subsequently changed the policy where they would by default federate entire domains instead.

Users were still prompted for the IBM ID when logging in. The login page would then redirect to the Azure AD login page if required or just authenticate if they are already logged in.

HI Scott,

Thank you for the feedback. 

As far as I understood from IBM they join the entire domain to federate the client's users on their corporate IDs.

Are your users using SSO when logging in or an IBM ID (username) and password?

Hi,
We have our IBM ids federated, but not the whole domain.  Each time a user wants access to PAoC we open a support ticket and add them to our federation.  After they are added, only then do we add them as users to PAoC. 

I haven't done the AD integration in over a decade but does Federated mean in your application?

Shahhere

Thanks for the reply Shahhere. We do something similar currently for the on-premises models currently running.

There is also the IsDisabled flag which could be set.

I think the main issue here still is the fact that the entire domain is federated which is likely to impact other users in other areas.

The next step I guess would be to assess how many and what systems etc. would be impacted before deciding which authentication method to choose.

Coming in late to this thread but we use the ClientProperties rule method to Add user based on their AD ID and match their domain.  When the click on Architect/Persectives it does the UserID@UserDomain match.  If a person cannot logon to a company machine then they wont be able to get to a TM1 system as when AD ids are disabled etc.

Not sure if this helps but it does keep it simple and still has a high level of security.

Shahhere

Thanks for the detailed response Paul, appreciate it!

The management and risk mitigation through managing access through groups etc. on the domain is very useful and was something we had discussed. Definitely easier than requiring a two step approach to removing someone when they leave/transfer as this would likely be done by different people in different teams.

Lots to ponder but we are much further ahead now than we were.

Just on your last line regarding SAML, for others reading this, IBM only use SAML, our client has ODIC/MS Entra and this won't work which means they will need to enable SAML and share certificates etc. Another sticking point with InfoSec.

Hello George,  

The Domain vs Application federation concern is one that I come across quite regularly.  There is not really a current alternative to federating the Domain as the federation is a company to company federation (more info: https://www.ibm.com/docs/en/ief?topic=welcome-introduction).

So, option is federate the domain or no federation.

Usually, the arguments for domain federation are strong with the clients CISO. ie, Authentication for all IBMid enabled offerings is then controlled by the client.  An individual leaves the organisation, gets removed from the idProvider and you can guarantee they can no longer access any of the offerings using it. 

The challenge is its a bigger piece of work as the impact is sometimes unknown.

The place to start is, after raising the federation request via support, the domain is verified and the Business Owner (BO) is identified, the BO can request a list of current IBMid in use on the domain.  This can help track down who is using an IBMid enabled application and also highlight how many ids pose a risk (a recent client had 300 IBMids for users who had left the company but could still possibly access an application if they had not been removed).

It's also worth looking at the impact of IBMid applications once federated.

It should be noted that its not all offerings IBM sell.  on premise applications do not tend to use IBMid.  It's mainly cloud applications (IBM Cloud, PAoC, CAoC etc). so this reduces the affected offerings.

One application that impacts other offerings is IBM my support.  The support case system uses IBMid for logins.

The impact of a user becoming federated is, 98% of the time, transparent to the application.  what does this mean?  simply that, in general, the application doesnt know the difference between a federated IBMid and non-federated so nothing breaks,  the application continues to work as expected.  The only real change is that the user enters their email address and then gets redirected to their internal login page (or SSO if already logged in) vs asked for a password. 

Now,  I say 98% of the time.  The edge case is if there is any automation/non-interactive processes that use the login credentials to perform tasks with an application.  Moving to federated (SAML based) could mean another approach is needed for these.

Hope this helps

------------------------------
Paul Hart Prieto

Original Message:
Sent: Wed February 28, 2024 04:39 AM
From: George Tonkin
Subject: Migrating to PAoC and Federated Login

Hoping that someone who has gone through a similar migration can share some insights.

We have a banking client who has been using TM1 on premises and is migrating to PAoC.

We are stuck with the clients InfoSec team as we cannot simply enable federation as this does the entire domain/all users.

The client is running legacy IBM products, mainframes, middleware etc. etc. Enabling federation for the domain will have untold impacts on users and systems.

Has anyone found a way to do SSO but without needing to federate the entire domain?

Have you perhaps gone the IBM ID where users login in with their IBM ID credentials?

Something else?

Any advice welcome - thanks in advance!