Talk:Single sign-on

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Internet (Rated C-class)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Single sign on vs. single sign off[edit]

The current version of the article says that "Single sign-off is the reverse property whereby a single action of signing out terminates access to multiple software systems". I think that describing single sign off as the reverse of SSO is not accurate. The reverse would be something like prompting for a username/pwd each time a user accesses a new system in the environment. Opinions?? --Eyad — Preceding unsigned comment added by 217.165.19.30 (talk) 06:37, 28 December 2011 (UTC)

 Done - Reworked the sentence. --M4gnum0n (talk) 09:28, 12 June 2012 (UTC)

Possible conventional authentication support[edit]

"Can support conventional authentication such as Windows credentials (i.e., username/password)" The wording of this statement needs improvement, that statement doesn't demonstrate any kind of any additional benefit from SSO that isn't already covered more generally in that list. I could go further to say, if it's not a given, how is it even relevant? Perhaps it should go in a hypothetical use case list.--58.96.105.16 (talk) 14:23, 14 July 2010 (UTC)

 Done - Removed. --M4gnum0n (talk) 09:31, 12 June 2012 (UTC)

ESSO Security Benefits?[edit]

In the ESSO section, it seems incorrect to say "significant security upside with client side ESSO solutions" and much like a brochure. In practice, SSO benefits the usability of systems, but does not add to any security. In many cases, this can be detrimental. —Preceding unsigned comment added by 74.140.173.132 (talk) 01:12, 20 October 2009 (UTC)

Use of the em dash[edit]

Could someone provide justification for use of the em dash in this term? More common usage seems to be without it ("Single Sign On"). The SNIA Dictionary is going to go without it in the absence of a strong argument for it. Alan Alanyoder (talk) 19:21, 30 May 2008 (UTC)

Yea, I agree with the use of the em dash, that, it should go. I think this confusion is similar to the debate with email and e-mail. It's worth noting that people write "single signon" "single sign-on" and "single sign on" -- I need for the sake of people being able to find this article, we need to think about redirecting anyone typing the above three to this article. Let's make it "single sign on" but make sure we code in "redirections" for those typing any other ways. ken knguyeniii —Preceding comment was added at 05:43, 26 June 2008 (UTC)

Merging with Enterprise Single Sign-on[edit]

With respect to merger proposal from Aug. 2007: No discussion seems to have taken place. My vote: MERGE. Vigilius (talk) 21:25, 8 April 2008 (UTC)

I agree: MERGE. ESSO is an element of SSO, although really a different technology. :) —Preceding unsigned comment added by Dpuryear (talkcontribs) 18:36, 24 April 2008 (UTC)

Looks like someone already had it merged. I redirected ESSO to this article and removed the tags. Jauerbackdude?/dude. 13:12, 1 July 2008 (UTC)

SSO internally[edit]

Can someone tell me how SSO works internally and how it talks to the IIS server etc...

Go look at SPNEGO -- DLeonard 02:53, July 21, 2005 (UTC)

This page just changed from yesterday. There is now an entry regarding CoSign, which is apparently some sort of open-source identity management product. I don't think CoSign should be listed as a type of Identity Management. It appears to me to be a specific implementation of Web Single Sign-On, not a specific category unto itself.Josh (josh.nospam@jrandrews.net)

Reversion as of June 16, 2006[edit]

(diff: [1]) I removed a series of edits which appeared to be advertising; the subject of the edits did not return any relevant Google hits and did not appear to be a highly notable service. If you are the user to made these changes, I apologize for the intrusion and encourage you to see WP:WEB, WP:NOT, WP:AUTO, and WP:SPAM. Especially if I have made these reversion in error, you have my most sincere apologies. If you wish to replace these edits, please offer your reasoning here. Luna Santin 08:46, 16 June 2006 (UTC)

OpenID[edit]

Was OpenID overlooked or is there a reason for it not appearing on this page? Pyroman 15:26, 9 August 2007 (UTC)

OpenID is an authentication framework while this page speaks of SSO as an access control mechanism in the first paragraph. We can comment somewhere in the Criticism section that SSO is a misnomer, though. Sam lowry2002 (talk) 09:44, 21 April 2010 (UTC)

Zennovation Removed?[edit]

Hi.

I added a sign-on provider to the list but it was removed but there was no reason as to why it was. Can anyone tell me why it was removed? Was it the fact that the provider is still in beta while revamping to become a public service or the way I wrote the information about it? —Preceding unsigned comment added by 149.254.200.218 (talk) 00:28, 1 November 2007 (UTC)

You're supposed to cite reliable sources when introducing information to Wikipedia; you should *NOT* include external links other than citations.
In any case, it doesn't matter, I have removed the list altogether because this article looked like yellow pages rather than an encyclopedia entry. -- intgr [talk] 01:27, 2 November 2007 (UTC)

Ok no problem. I was just wondering, I'm not really an expert of Wiki editing, usually just use it for reference, and I was not going to put and external link in untill I saw one in another, but no problem. Thanks for the info. —Preceding unsigned comment added by 88.109.94.238 (talk) 16:32, 2 November 2007 (UTC)

Enterprise service-oriented architecture[edit]

I removed the section on Enterprise Service-Oriented Architecture. That's just SAP's name for SOA. Many of the statements were forward looking: "will have an impact on", "likely that future SSO solutions", etc. Here is the text I removed:

Single Sign-On for Enterprise Service-Oriented Architecture
Enterprise Service-Oriented Architecture, also known as E-SOA (also see Service-Oriented Architecture), will have an impact on authentication technologies and architectures. It is likely that future SSO solutions will evolve according to new customer needs in real-life E-SOA environments. Furthermore, there is a growing concern over the applicability of current SSO solutions for E-SOA platforms provided by SAP or Oracle Corporation. There are new developments in SSO technology designed to offer "E-SOA compatibility."
Client Certification-based SSO in E-SOA
Client certificates is an authentication method that supports a secure single sign-on to some ERP E-SOA based platforms (e.g., SAP)
Kerberos-based SSO in E-SOA
Some E-SOA platforms will not be compatible with Kerberos-based SSO. SAP E-SOA is one example.
Supported SSO Mechanisms for SAP E-SOA
1) Username / password
2) Client Certificates
3) SAP Logon Tickets
4) SAML (combining SAML and Kerberos not planned)

Maybe this wants to go in the SAP article? --Ishi Gustaedr (talk) 21:01, 10 July 2008 (UTC)


Agreed. this should go in the sap article. this could also go into the service-oriented architecture article...i don't think there is an e-soa article yet. it would be nice to have someone build it.

OpenID can be an SSO system[edit]

The article contains the claim "Shared authentication schemes like OpenID, which require additional sign-on for each web site, are also not single sign on".

First of all, OpenID would not generally be considered a shared authentication scheme. When you use an OpenID to log in to a relying party, the relying party doesn't directly authenticate the user: instead it asks the OpenID provider whether the user is authenticated. The relying party never has enough information to independently identify the user, which is the usual case for shared authentication.

While not required by the spec, most OpenID providers only require the user to authenticate once during a session (e.g. using session cookies or relying on SSL client certificates that the user unlocks once). So in most cases, the user only signs on a single time.

Lastly, it is quite easy to build a traditional closed SSO system with a central authentication server using OpenID 2.0's directed identity mode. This could either be a company provider for intranet apps, or as a way to rely on Google's or Yahoo's account systems for an internet app. --James (talk) 15:08, 12 May 2009 (UTC)

Makes sense; are there any sources that discuss using OpenID as a SSO system? If so, I can't see any problems with changing this. -- intgr [talk] 22:08, 12 May 2009 (UTC)
I've built such systems, but haven't published anything on it. There is Google's documentation on implementing federated login here which might count: it describes using a fixed endpoint URL and directed identity to start the authentication process without having the user provide an identity URL, which is pretty much how the systems I've built work. --James (talk) 23:55, 12 May 2009 (UTC)

"See also" subsections[edit]

The "see also" section seems to be rather lengthy, perhaps we could organize it under a few subheadings? I will try to get around to it sometime soon, but I invite the rest of you to give it a go. ...but what do you think? ~B Fizz (talk) 22:36, 20 August 2009 (UTC)

i agree that it is rather long. The suggested reorganisation would probably be an improvement, but I think better still would be to cut most of it out: some of the topics are fairly indirectly related, and it seems to me "see also" sections should give just the most significant links. JamesBWatson (talk) 09:08, 14 December 2009 (UTC)
I reorganized the content under the headings "Underlying concepts", "Related technologies", and "Implemetations of single sign-on". Unfortunately, I'm really not knowledgeable enough to determine what to delete, but perhaps we should break the "Implementations of single sign-on" section into a list of its own: List of implementations of single sign-on. Then we could simply "see also" a link to that list. ...but what do you think? ~B Fizz (talk) 18:45, 15 December 2009 (UTC)
Since it seemed like the thing to do, I did it. The see also section now has only 4 links. =) Please review the changes and comment/act thereupon. ...but what do you think? ~B Fizz (talk) 18:58, 15 December 2009 (UTC)
Much better. Thanks. JamesBWatson (talk) 15:06, 7 January 2010 (UTC)

SAML[edit]

I'm a newcomer to this topic, but I was surprised to see no mention of SAML. Is that intentional? The SAML page currently says "The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO) problem" which makes it seem relevant. Chris Dolan (talk) 19:21, 22 August 2011 (UTC)

 Done - Added a link in the "See also" section. --M4gnum0n (talk) 09:47, 12 June 2012 (UTC)

Resources[edit]

I am posting a white paper about this topic under resources and it keeps getting deleted. Does anybody know why? — Preceding unsigned comment added by DParisotti (talkcontribs) 15:46, 12 September 2011 (UTC)

If you click View History on the article, then you can see the edit summary given by the editor who reverted your change. The reason given was that the link you added requires some form of sign-up (or at least, surrender of personal information) for use. This is not permitted for external links; see WP:ELREG. From a brief glance, the "white paper" you tried to link to, also seemed aimed at selling some sort of support service or similar product. That's not what Wikipedia is for. --Demiurge1000 (talk) 16:52, 12 September 2011 (UTC)

Definition[edit]

SSO is not a property, but a capability offered by access control systems — Preceding unsigned comment added by Mullachv (talkcontribs) 05:04, 1 December 2012 (UTC)

I am not sure I agree with "...single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication..." near the top. I agree that one method of implementing an SSO solution would be to store a bunch of credentials and do look-ups against some initial credentials. Another approach is to have different systems collaborate to use a single set of credentials provided by a central identity provider, and to have secure message exchange between the identity provider and parties that rely on that provider.

I understand that implementing such an identity provider involves maintaining sets of certidicates or name/password pairs that underlying systems use to know each ohter, but this is not the same as maintaining a set of credentials for each user that authenticates with the SSO. A name and password that identifies the accounting system is not quite the same concept as a name and password for each user of the accounting system.

I don't know that I have a good replacement sentance for the one I don't like. I might just erase the sentance, but that would maybe beg questions.

Contrast ESSO used by Microsoft BizTalk [1] with Access Control Services used in Microsoft Azure[2]

--Skip (talk) 17:19, 5 February 2013 (UTC)

Reopening discussion about SSO versus OpenID, to include OAuth, OpenID Connect and Facebook Connect.[edit]

I just updated the opening section of the single sign-on article to try to distinguish between true SSO (based on the work of the formal user groups and how Google federates all their apps), versus OPenID, OAuth, Facebook Connect, etc, where I thought you have to sign in each time. I included a source saying that OpenID was not technically SSO, but instead is pluggable authentication with a shared database [[2]]. I also looked at the different standards bodies to get info direct from the source. Opengroup.org has a page showing how SSO is supposed to work, where the login info is passed to the secondary sources without the user having to do anything but click.[[3]] The National Information Standards Organization (NISO) has an SSO initiative called ESPRESSO where they are trying to draft true single sign-on, and in the call for the draft document they specifically mention Athens and Shibboleth as being true SSO, but only if the participating sites have agreed on which one to use.[[4]] I went to the OpenID COnnect site and found their spec, and it does say that the OpenId process can be automatic, at least that's how I'm reading section 3.1.2.1. Authentication Request on [[5]]. My personal experience is that I'm prompted every time - I've never gone to a web site where I was automatically logged in and it said "Welcome Tim" or something like that on the top.

I looked in the other comments on this talk page and saw that there were two old previous discussions about this - one saying SSO and OpenID are different user:Sam lowry2002, and one saying they were the same, but without providing any sources user:JamesHenstridge. Here's a blog listed as an external link which heavily mixes and matches the terms SSO and OpenID [[6]]. I"m not sure what's right. Anyone have any additional insight about OpenID and whether it is expected to function as true SSO? If not, the entire security section, which only discusses OAuth, needs to be updated.Timtempleton (talk) 15:44, 23 May 2014 (UTC)

I said that OpenID can be used to build a Single Sign-On system, and I stand by that. I agree that many sites implementing OpenID are not implementing SSO, that doesn't mean that OpenID can't be used to implement it.
Rather than requiring the user to click a "log in" button, there is nothing stopping Relying Party web sites from starting the authentication process without prompting by the user. This could either be done when the user first visits the site or when they do something that requires authentication (e.g. as part of the checkout process on a web store, editing a wiki page, etc). If you want to do this without user interaction, you'd need to use a fixed identity URL to start the authentication procedure. With OpenID 2.0's identity select mode, this isn't such a problem: you can use an Identity Provider's identity URL instead. In this way, the IdP can authenticate as any identity URL it manages in the response.
On the Identity Provider side, it knows which RP it is talking to and knows who the user is through browser credentials (cookies, client certificates, basic or digest auth, etc). While the IdP could ask the user if they want to provide their identity to the RP, if could also complete the authentication process for recognised RPs without user interaction. If you put these two together, an RP could transparently authenticate a user provided they have previously authenticated to the IdP. --James (talk) 02:40, 10 June 2014 (UTC)

Add Atlassian Crowd reference[edit]

https://www.atlassian.com/software/crowd/overview/ — Preceding unsigned comment added by 190.216.150.147 (talk) 13:37, 14 March 2016 (UTC)