It would be nice if the products included a configurable SSO interface. There are several different approaches to SSO: - *Agent Based*: Generally uses an http header to pass information from the agent to the web server and has it's own standalone infrastructure for handling authentication, password resets, etc. This includes Oracle's SSO solution, SiteMinder, Kerberos, etc. - *IdP/SP based*: Generally a SAML assertion. This most commonly used by your SaaS providers. This typically requires a framework be implemented within the application that can speak SAML -* Others*: WS-Federation/WS-Trust, US eAuth, OpenID, OAuth, etc.
Each of these have a different architecture and address the needs of different types of organizations. *Agent Based*: The agent based is probably the most common among the Remedy community. The agent based approach typically has an agent that sits on a web server. This agent handles protecting certain resources on the website and handles the access/authentication to those resources by directing users to the appropriate interface for authentication. The agents generally pass information to the application server, either in the form of an HTTP header, java session attribute, or some other mechanism. To give a simple interface to consume the authentication information, the Remedy products could allow for the consumption of the values passed by the agent to the mid-tier using common methods of transport (i.e., HTTP header, Session Attribute). This could be accompanied by an AREA plugin that knows the information is coming from a trusted source (shared secret). This could be opened up for people to write more elaborate plugins if the mid-tier configuration interface provided a pluggable interface so that people could write/package modules for the mid-tier that exposed the configuration through the mid-tier configuration interface. This is implemented in other popular applications like Trac, Joomla, etc. and is not a new concept. *IdP/SP based*: These are generally used by SaaS providers and consumers. As either a provider or a consumer of SaaS application, SAML assertions can be used to allow seamless authentication with both your internally hosted COTS applications or your externally hosted SaaS applications. The applications generally have to be aware of SAML to allow for the configuration specifics. There are some ways to mitigate this by installing web server modules that you can configure with the SAML specifics, which in turn expose the appropriate data using the same means as the agent based solutions. The trick with the BMC application stack is getting them all configured to play together. The stack consists of various components from different vendors, each of which has it's own set of capabilities. Axton Grams The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. On Fri, Apr 1, 2011 at 2:39 AM, John Baker <[email protected]>wrote: > David, > > The vast majority of BMC AR System users are working in corporate > environments where they wish to open a browser, navigate to the Midtier, > and silently login. > > Some corporates will be using enterprise solutions such as Siteminder or > RSA Access Manager, and that's precisely the reason that users and/or > security teams will not want to install Atrium(Open)SSO. OpenSSO was > designed to compete with these products, not compliment them. > > Users don't want to find a separate server on which to install > Atrium(Open)SSO, and they don't want to manage an 'enterprise' solution > which even SSO trained consultants can't figure out how, or don't want, > to use. > > Users want something that they can easily install, is well supported, > was designed to integrate with AR System and "just works". I believe JSS > & SSO Plugin ticks all of those boxes, as confirmed by some of BMC's > largest clients who asked BMC for a solution, waited patiently, and then > approached JSS (and in some cases, found the solution delivered within > hours of contacting us). > > > John > > -- > Single Sign On for AR System > http://www.javasystemsolutions.com/jss/ssoplugin > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
