Hello
There was a question from someone in the BMC DN AtriumSSO community
asking for feedback (positive and negative) on AtriumSSO. I posted some
feedback but thought it may be useful to share it here, as not everyone
reads BMC DN (you know, ARSList is where it's happening :). My diatribe
follows.
The fundamental issue with AtriumSSO is that it's the wrong product
implementing the wrong architecture for use by the wrong audience.
The wrong product
If you want an enterprise SSO solution, ie a standalone "never intended
to integrate with AR System" solution, you have a choice of providers
(Ping, IBM, Microsoft, CA, RSA, Forgerock) and Forgerock is near the
bottom of the list for wide-spread corporate use. The sheer amount of
money BMC have spent attempting to shoe-horn OpenAM into their product
set could have been spent paying some other company to complete the job.
Whilst the outcome may have been equally difficult to use, at least the
core solution would be supported and improved by a company who has a
good grasp of the technology.
The wrong architecture
The "hub and spoke" model is a choice large organisations may make when
integrating their own SSO solutions with a single product. Or they may
host their applications in a farm and provide the SSO facility, with the
reasonable expectation that the end product will provide a generic SSO
implementation out of the box.
Yet, BMC have embarked on their own hub and spoke model, ensuring that
when an organisation has already adopted their own, the integration
effort is enormous.
For example, deploying AtriumSSO to read an HTTP header/cookie (a common
approach in the farm model) is complete over-kill. In the simplest
no-frills case, it's a few lines of Java amounting to a 20k class file.
20k, not 650Mbs of application or whatever AtriumSSO currently weighs.
For example, deploying AtriumSSO to integrate with Ping Federate means
you have a separate set of servers/load balancing configuration for your
AtriumSSO deployment, on top of the Mid Tier deployment, when Ping can
provide a perfectly sufficient integration module (that should fit into
Mid Tier) to avoid such a complicated deployment.
For example, deploying AtriumSSO to integrate with Active Directory to
provide Windows Authentication gives you all of the extra hardware
complexity for a half complete implementation of Windows Authentication.
Users would be better off with a copy of IIS and the BMC open source
community SSO code (less hardware, a BMC supported configuration, etc).
The wrong audience
The idea that BMC can package a complicated "corporate-SSO" solution
into a box and make it user friendly is both far fetched and not in line
with the principals that underpin BMC AR System.
Organisations invest in BMC AR System because it's easy to use and
deploy; because they can quickly modify a user interface to suit their
business needs. Those organisations are employing people with
business-analytic skillsets who have AR System development knowledge,
not people who enjoy managing their own Certificate Authorities. Sure,
there are exceptions - there are a number of ex-Perl/C/Java developers
who have moved into the AR System space, but the majority do not enjoy
the complexities of debugging SSL stack traces.
Indeed, I don't either. Despite years of trying, I still find mutual-SSL
with multiple Certificate Authorities difficult to get my head around.
Equally, ask me a business-analytic style question on ITSM processes and
I will politely decline to contribute. But give me a Fiddler or
Wireshark trace of some SSO related problem and I've got a fairly good
chance of providing an answer.
John
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
