It's interesting the way you mentioned that some companies operate, because I've seen other companies take the opposite approach. Since we're all beyond capacity of our work loads, and it is nearly impossible to hire someone, it is viewed as being better to buy software (which still requires an act of Congress) than to expect one of us to build it. A few thousand dollars extra of maintenance versus tens of thousands or more to hire someone is a huge cost savings. Plus, if the software doesn't work out, you can just stop paying maintenance and that's it. If you hire an extra person and things don't work out, you have a lot of issues to address in terminating them even in the most corporate-friendly of states.
On the topic of SSO, my management often start off conversations with our BMC account rep with some variation of, "Have you all bought JSS yet?" It's not that we necessarily think that's going to happen, but it was difficult for us to explain to our upper management that we needed to buy or build an SSO tool because BMC doesn't provide a real one in this day and age. All we needed was to not ask people to log in to Remedy when they hit a hyperlink if they were already on their network PC just like SharePoint and everything else does. Business Objects has its own built in SSO that we use so we really have no use for a product like AtriumSSO to pass Remedy credentials out to other applications. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, Lj Sent: Thursday, May 30, 2013 2:10 PM To: arslist@ARSLIST.ORG Subject: Re: Atrium SSO VS Other after market solutions ** I have personally always modified the login.jsp to not prompt for the authentication field, mainly because it confuses most users, so in my solutions, they don't have the ability to do a 'post' to the login servlet via my jsp pages and provide the proper 'key'....that is of course assuming they know what the key is (which I guess wouldn't be that hard to get with fiddler....but the community sso DOES provide a provision for you to limit the SSO to specific IP's...so even if someone were to know the key, and try to post from their own server...it would be rejected based on not being on the white list...so I consider that 'relatively secure' In regard to delegating sso to something else....you don't then have a problem with IIS providing the user name to the plugin? Is there anything inherently insecure with using the getRemoteUser method for obtaining a user name? I remember some postings in the past where you discussed that it's not the proper way of doing it...but I don't recall the exact verbiage. I have personally found that the 'roll your own' is likely quite often MORE expensive than a purchased solution...but the problem that you end up with is the fact that a company is quite often willing to continue paying 'person x' to do that rolling because their pay check is already in the budget, whereas even something as moderate as a few thousand dollars for a OTS solution is outside the realm of being paid for. Now...because I don't really know much about AtriumSSO, other than what I have heard from you in various forms, can you tell me what its shortcomings are vs other solutions? On Thu, May 30, 2013 at 12:36 PM, John Baker <jba...@javasystemsolutions.com<mailto:jba...@javasystemsolutions.com>> wrote: Lj You raise good points. On postings to BMC DN I often mention the open source solution, and suggest that if one does not want to pay for a solution, then the open source solution plus some other external tool is a good step forward versus wrestling with a rebranded OpenSSO. One of the downsides with the open source solution is, the last time I looked, it uses a fixed string for authentication. This means users can go to the standard BMC login page and login as anyone if they know the fixed string. Maybe it has changed - has it? You mention IIS. Yes, this can be used in conjunction with the above but from a pure security point of view, we are now delegating SSO to IIS and we leave Tomcat open to attack by some other means. This means one has to take additional measures to secure Tomcat and only allow access from IIS. I'm pleased you recognised that I wasn't pushing our own product. I tried to stick to the facts. But the reason people buy it is because the cost of building a bespoke, less mature, often poorly supported solution is not too much different to purchasing an SSO Plugin license. And the product offers vastly more than just SSO. So as I always maintain: building a solution is entirely achievable and given the community SSO solution plus additional measures, it can be made to work. Sorry if I forgot to add this point :) Note, JSS is not the only vendor of a third party solution. But the others tend not to put it on a website and allow anyone to download. John _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
