I tend to agree. I am not sure why they don't simply create a configuration page in their products that allows for the configuration of the most common SSO integration methods: - HTTP Header (provide name of the header, define trusted IPs, etc.) - SAML Configuration - Kerberos - Client certificates
Then document the configuration steps required to use the available methods. The pages to configure the authentication could look something like these: http://blog.newrelic.com/wp-content/uploads/SAML_screen.png https://www.netiq.com/documentation/idm401/agpro/graphics/ssoconfig1.png https://www.netiq.com/communities/media/img/13456-1.png http://indirat.files.wordpress.com/2009/08/sforce-sp-config31.png Though most of these authentication methods require some level of technical expertise to implement properly, most of these authentication methods are well known. The methods to hook into these using Java or C are well known and many libraries exist to do just that. The last thing I want to see is another solution to do the same thing as other solution(s) within the enterprise. Competing products in the same space is a waste of time and money and integrating the two typically proves challenging and expensive and wrought with compromise. Bundling a completely separate piece of of an enterprise infrastructure with your product to do what most enterprises already do makes little sense to me. Axton Grams On Thu, Nov 14, 2013 at 6:26 AM, John Baker <jba...@javasystemsolutions.com>wrote: > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
