This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
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)
"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)
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)
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)
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 ( talk • contribs) 18:36, 24 April 2008 (UTC)
Sincerely this a support programme for any person Sting omugezi wecilifeli comquer ( talk) 12:19, 14 May 2022 (UTC)
Can someone tell me how SSO works internally and how it talks to the IIS server etc...
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)
(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)
Was OpenID overlooked or is there a reason for it not appearing on this page? Pyroman 15:26, 9 August 2007 (UTC)
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)
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)
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:
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.
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)
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 F izz ( talk) 22:36, 20 August 2009 (UTC)
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)
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 ( talk • contribs) 15:46, 12 September 2011 (UTC)
SSO is not a property, but a capability offered by access control systems — Preceding unsigned comment added by Mullachv ( talk • contribs) 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)
References
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)
https://www.atlassian.com/software/crowd/overview/ — Preceding unsigned comment added by 190.216.150.147 ( talk) 13:37, 14 March 2016 (UTC)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
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)
"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)
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)
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)
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 ( talk • contribs) 18:36, 24 April 2008 (UTC)
Sincerely this a support programme for any person Sting omugezi wecilifeli comquer ( talk) 12:19, 14 May 2022 (UTC)
Can someone tell me how SSO works internally and how it talks to the IIS server etc...
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)
(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)
Was OpenID overlooked or is there a reason for it not appearing on this page? Pyroman 15:26, 9 August 2007 (UTC)
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)
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)
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:
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.
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)
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 F izz ( talk) 22:36, 20 August 2009 (UTC)
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)
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 ( talk • contribs) 15:46, 12 September 2011 (UTC)
SSO is not a property, but a capability offered by access control systems — Preceding unsigned comment added by Mullachv ( talk • contribs) 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)
References
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)
https://www.atlassian.com/software/crowd/overview/ — Preceding unsigned comment added by 190.216.150.147 ( talk) 13:37, 14 March 2016 (UTC)