Thanks for sharing your experience Sylvain!
Original Message:
Sent: Fri May 15, 2020 08:12 PM
From: Sylvain Gilbert
Subject: Pondering TFIM to Cloud Federation
Hi Shane and all
I would like to re-enforce your point of automation and DevOps. In the ITFIM days (or even ISAM software stack as in V7), we could do some level pf automation but that was with different command lines and disparate tools. Now with the unified ISAM v9 (Virtual Appliance or Docker) we have found a DevOps friendly platform where all new investments that we made so far in our transformation journey (adopting Git, Ansible, Python…) are paying back already. We do more development now and less repetitive operations, and I believe that makes pretty much all team members happier, and we seem to have now an infinite backlog of good ideas to make our automation stack do more to help bring more value-add to our IT partners overall.
As for the ITFIM->ISAM migration, we did it in somewhere less than 60 days including coding, running processing of data export from ITFIM->Git->Massaging->Import to ISAM for about 40-50 feds. We did not need to contact our SaaS vendors as we kept our URL identical but of course we were well prepared and rehearsed. We decide to go that route after a preliminary pilot that demonstrated that we could rapidly apply small updates with our automation should the need arise. It provided us also more agility, and since everything is in Git, our knowledge base (configuration registry) is well protected and versioned. And we can rebuild any Virtual Appliance from scratch and be confident we can redeploy all federation no sweets.
As for going IDaaS cloud or not, the notion of DevOps in my mind will already remain relevant for provisioning your federations into the Cloud offering, as you would for provisioning your AWS EC2 instances if you believe in the value proposition of DevOps.
Cheers
------------------------------
Sylvain Gilbert
Original Message:
Sent: Thu May 14, 2020 03:49 AM
From: Shane Weeden
Subject: Pondering TFIM to Cloud Federation
Understand, but measure the cost objectively. The XSLT -> Javascript conversion is highly unlikely to be significant, even for 100+ federations and partners. I would strongly suspect there sre a lot of similar rules, doing identical or near-identical mapping operations. In Javascript you can write common functions and import them into other mapping rules. This will reduce the TCO over time as there will be less to maintain.
The more significant burden, being borne by everyone in modern IT, is digital transformation to automated devops processes. An up-front cost that is returned over time for sure, but one that I am certain is worth the effort. I wonder, for example, how many security vulnerability patches have not been applied in older software-based systems like that which TFIM is running on? How quickly can you [safely] respond to that, etc, including fallback to a previous version or patch level? Those things are generally not measured or taken into consideration until you become the victim of an attack.
I would implore you to keep a broader perspective than just the transactional cost of going from TFIM->ISAM and XSLT->JavaScript. The value proposition is much more significant than that.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Wed May 13, 2020 11:50 PM
From: Jeff Stieglitz
Subject: Pondering TFIM to Cloud Federation
Thanks for the continued collaboration!
I'm really looking to manage the costs of staying at supported software levels. It seems to me, without any objective evidence, that converting a bunch of XSLT to Javascript will require developers and testers. Since TFIM was discontinued, it looks like I will need to do a lot of development to move to something that is supported. Sometimes it happens I guess, depending on how the technology is received by the marketplace. In our case, we made a bet on TFIM and XSLT, and now we have to pay to move.
Naturally, I was hoping for a code converter or something that would reduce the transition effort.
------------------------------
Jeff Stieglitz
Original Message:
Sent: Wed May 13, 2020 07:11 PM
From: Shane Weeden
Subject: Pondering TFIM to Cloud Federation
Well I'm glad to hear our products have served you well. IMO though XSLT is a dinosaur and really not the best language for identity mapping. I think the simple JavaScript pattern we have exposed and the rich utility classes you can leverage from it are a vast improvement. Also the primary advantage to moving to ISAM in either Virtual Appliance or containerized deployment is the natural fit into modern automated devops practices.
Regards,
Shane.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Wed May 13, 2020 07:03 PM
From: Jeff Stieglitz
Subject: Pondering TFIM to Cloud Federation
Thank you, Shane. I'm looking for a solid value proposition to justify the cloud convenience. If the cloud service mimics the TFIM XSLT capabilities, the simplified transition might justify the cost on its own. I'm a bit mystified at the complexity of upgrading TFIM and also ISIM to their next versions. They have served us well for many years and I'm looking for a smooth path to continue to leverage the benefits.
------------------------------
Jeff Stieglitz
Original Message:
Sent: Mon May 11, 2020 03:38 AM
From: Shane Weeden
Subject: Pondering TFIM to Cloud Federation
IMO you may find that a hybrid solution is best, and this is where I believe the IBM solution differentiates itself.
For common SaaS apps you are using and that your own company maintains that support standard SAML 2.0 browser post flows, it makes a lot of sense to use the IBM Cloud Identity SaaS offering as the IDP for them. Easy, permanent point-and-click style configuration.
You can in turn (and this is where hybrid kicks in) use on-prem ISAM as an "Identity Source" for your Cloud Identity Tenant. Yes this means that users of those apps use Cloud Identity as a pass-through service - it is an IDP to the SaaS app, and an SP to the on-prem ISAM.
For other federation partners you could initially leave them partnered with on-prem ISAM directly, even preserving the existing SAML URLs and signing keys such that the partners need ZERO updating. Over time, as you do get contacts for those partners, migrate them to use the Cloud-based IDP directly. You may even eventually get to a point where you deprecate the on-prem ISAM altogether, or get to a point where *most* apps are partners of Cloud Identity, therefore you make it the primary point of authentication and turn the on-prem ISAM into an SP of Cloud Identity.
This is a relatively common cloud transformation journey that I see customers undertaking as they move to a cloud-based IDaaS.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Sat May 09, 2020 01:39 PM
From: Jeff Stieglitz
Subject: Pondering TFIM to Cloud Federation
I have been pondering my options since TFIM went end-of-support in September 2019. It looks like ISAM offers federation capabilities, so that's certainly one approach; I see here in the forums that several of you have gone that way.
We have over a hundred federations and leverage the XSLT transformation capability of TFIM...a capability that ISAM lacks. Looks like we will need to re-write those transformations in JavaScript if we stick with ISAM.
That will be a good chunk of work.
So now I'm wondering if I would have an easier and more forward-looking solution if I used IBM Cloud Identity Connect, Ping Federate, or maybe Azure. Most of my federations will not take advantage of the pre-built integrations of those services, but their catalogs of integrations are certainly a plus.
I would appreciate any words of encouragement or commiseration with IBM IAM users who have significant federations using a cloud aggregator like Ping, IBM, or Azure.
Snark: IBM is usually so good about "investment protection", I'd rather be doing something value-add than this thankless migration. It's going to be quite a challenge to even find valid human contacts for these 100+ federations.
------------------------------
Jeff Stieglitz
------------------------------