The intended audience for this document is appliance and software product vendors. The background is we’d like appliance vendors to support Single Sign On mechanisms\u00a0natively.<\/p>\n
This is shared sign on, not true single sign on. Users visiting shared sign on protected sites enter the same credentials in each site to access each facility in turn. Although this is better than having many passwords to remember, the more you convince your users it\u2019s ok to type their credentials into multiple web interfaces, the more exposed they are to two threats<\/p>\n
The user visits your site, your site redirects to an (external to your appliance) authentication portal, the user successfully authenticates and your site then receives the user plus a cryptographic token. If the user visits any other SSO enabled site, then that token already exists, so no login is needed, they seamlessly access the next site without any login credentials using the token.
\nThe appliance\/site never sees the user login credentials themselves and the authentication portal is always the same site.<\/p>\n
A truly SSO site would have the user log in in the morning, and then their mail client, web browser and other applications don\u2019t need a password entered as they all use the SSO authentication as the token.<\/p>\n
It’s not any more complicated than your existing modules. As an appliance vendor, where you have your existing LDAP and Active Directory authentication\/authorisation modules, you\u2019d add a third, the packages for common platforms are prebuilt, there\u2019s a little configuration, it\u2019s not a big deal. You could use Webauth with LDAP or you could use Shibboleth.<\/p>\n
As an example, if your product is using Apache under the hood, you could install the webauth authentication module along aside your existing authentication modules and with a minor amount of system configuration you will have $REMOTE_USER value available to your application as per normal, once the user authenticates. Then use LDAP to get group\/authorisation details.<\/p>\n
If you use the Shibboleth based SSO method, then you don\u2019t need LDAP for group\/authorisation information as the details will be appended as user attributes in the information provided to the application by the authentication module. Shibboleth is using SAML, it\u2019s fairly straight forward if you\u2019ve already built the ability into your product to use LDAP and Active Directory.<\/p>\n
Firstly this is using technology used by multiple other universities, it\u2019s not unique to our site, and no doubt more sites would use it if any appliance vendors supported the technologies involved (see also IPv6, which until recently took a long time for vendors to take seriously).<\/p>\n
Secondly, to some degree feature requests are self-selecting \u2013 potential customers look up vendors products, see that they don\u2019t support the technologies they need, and then go off to create a solution or workaround without contacting the vendor.<\/p>\n
Mentally put yourself in the shoes of your customer
\nThey have just implemented your product, it\u2019s deployed and working. They are not likely to want to suddenly change the authorisation and authentication. For a complex environment this would typically only come about from service review and replacement. In laypersons terms \u2013 if it isn\u2019t broken (already deployed and working), customers won\u2019t typically attempt to fix it, especially something as fundamental as the authentication\/authorisation mechanism.<\/p>\n
If you are the first and only vendor to support Single sign on, then over time word will spread and you will be the known appliance vendor in your niche that Single Sign On capable sites go to. They will overlook minor flaws because you support this key feature.<\/p>\n
This is already implemented and working site wide for many years. The only exceptions come when we\u2019re forced to use a vendor\u2019s product that has no facility for apache authentication modules, or built in support for either Webauth or Shibboleth.<\/p>\n
Other sites using this technology include any site using Stanford Webauth<\/a> or Shibboleth<\/a><\/p>\n If you support this feature, you will gain more customers and so earn more money in the long term. Customers (new and existing) will be happier because they have the option of deploying a new or integrating an existing Single Sign On site-wide system that includes your product.<\/p>\n","protected":false},"excerpt":{"rendered":" The intended audience for this document is appliance and software product vendors. The background is we’d like appliance vendors to support Single Sign On mechanisms\u00a0natively. SSO? Yes, we already support LDAP and Active Directory against which to authenticate logins to … Continue reading What\u2019s the bottom line?<\/h3>\n