OpenID and SSO

[Mayukh gon]

Some parts of this message have been removed. Learn more about Nabble's security policy.

The same as what wikipedia describes it:

 

Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems.

As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.

 

 

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Williams]

But note the very bias built into the definition! The fighting has moved on to the wikipedia front, now.

To many folks SSO/CCA is at most an authentication method, not a method of access control. In trusted system evaulation criteria, one MUST distinguish between authentication and access controls. SSO is a variant of the kerberos logon service, there! Others believe its time to discard that distinction, and let an attributed authentication statement act as an access control ticket.


________________________________
From: general-bounces@... [general-bounces@...] On Behalf Of Mayukh gon [totuis@...]
Sent: Thursday, June 26, 2008 9:44 AM
To: general@...
Subject: [OpenID] OpenID and SSO

The same as what wikipedia describes it:


Single sign-on (SSO) is a method of access control<http://en.wikipedia.org/wiki/Access_control> that enables a user to log in<http://en.wikipedia.org/wiki/Log_in> once and gain access to the resources of multiple software systems without being prompted to log in again. Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems.

As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.





_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[NISHITANI Masaki]

Basically, there is a fundamental conflict between ordinary
SSO and OpenID, I think.

SSO is to be defined an authentication/authorization method
to treat many sites as one. In SSO world, an end-user does
not need to care which site it is actually visiting.

In contrast,the purpose of OpenID is to accept the result of
authentication (assertion) from other sites. OpenID is
designed to distinguish one site from another.

Technically, SSO requires sites to know which identity
provider (IdP) the user belongs to without any user
interaction. Usually this is implemented to configure only
one IdP in sites, and as the result, the every sites make up
a closed circle of trust.

In OpenID world, that is an open world, an user can choose
any IdP (OpenID provider as OpenID term) and RP can accept
assertions from hundreds of OPs. To realize this, RP should
process the OP selection before making an authentication
request. This means usually OpenID require an
user-interaction as the first step.

It is true that RP can do the first user-interaction
implicitly with cookies, or skip it always using hard-coded
OP. But those are not typical SSO nor OpenID use-case.
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Dick Hardt]

I agree with your analysis on how OpenID and SSO implementations often  
work today.

Presuming one of our objectives is to simplify the user experience of  
logging into websites. From the users point of view, they  want to  
login once and be done with it. This is the user view of SSO.

OpenID does achieve this in the right  circumstances.

*if* the RP remembers the user's OpenID the first time they visit the  
site and the user only uses one OpenID on the site, then when the user  
returns, and if the RP autofills the OpenID in the form, then the user  
just has to click the submit button to login (assuming they have a  
valid session at their OP and their OP is configured to automatically  
login to that RP

Lots of assumptions in this flow, definitely room for improvement.

Question: do people think improving this is important?

On 26-Jun-08, at 6:57 PM, NISHITANI Masaki wrote:

> Basically, there is a fundamental conflict between ordinary
> SSO and OpenID, I think.
>
> SSO is to be defined an authentication/authorization method
> to treat many sites as one. In SSO world, an end-user does
> not need to care which site it is actually visiting.
>
> In contrast,the purpose of OpenID is to accept the result of
> authentication (assertion) from other sites. OpenID is
> designed to distinguish one site from another.
>
> Technically, SSO requires sites to know which identity
> provider (IdP) the user belongs to without any user
> interaction. Usually this is implemented to configure only
> one IdP in sites, and as the result, the every sites make up
> a closed circle of trust.
>
> In OpenID world, that is an open world, an user can choose
> any IdP (OpenID provider as OpenID term) and RP can accept
> assertions from hundreds of OPs. To realize this, RP should
> process the OP selection before making an authentication
> request. This means usually OpenID require an
> user-interaction as the first step.
>
> It is true that RP can do the first user-interaction
> implicitly with cookies, or skip it always using hard-coded
> OP. But those are not typical SSO nor OpenID use-case.
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Eric Norman]

On Jun 27, 2008, at 9:25 AM, Dick Hardt wrote:

> *if* the RP remembers the user's OpenID the first time they visit the
> site and the user only uses one OpenID on the site, then when the user
> returns, and if the RP autofills the OpenID in the form, then the user
> just has to click the submit button to login (assuming they have a
> valid session at their OP and their OP is configured to automatically
> login to that RP
>
> Lots of assumptions in this flow, definitely room for improvement.
>
> Question: do people think improving this is important?

Well, I certainly think that the fewer actions that a user has
to perform, whether they by physical (e.g. clicking) or cognitive
(e.g. remembering), then the more riskier and less safer the login
process is from the point of view of security.  This does assume
that the user has close to an accurate understanding of the action
she is about to perform.  The latter is a lot more difficult to
effect then most with geek training believe.

To reiterate, the main point here is that fewer user actions
imply less safety.

Eric Norman

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Dick Hardt]

On 27-Jun-08, at 12:25 PM, Eric Norman wrote:

>
> On Jun 27, 2008, at 9:25 AM, Dick Hardt wrote:
>
>> *if* the RP remembers the user's OpenID the first time they visit the
>> site and the user only uses one OpenID on the site, then when the  
>> user
>> returns, and if the RP autofills the OpenID in the form, then the  
>> user
>> just has to click the submit button to login (assuming they have a
>> valid session at their OP and their OP is configured to automatically
>> login to that RP
>>
>> Lots of assumptions in this flow, definitely room for improvement.
>>
>> Question: do people think improving this is important?
>
> Well, I certainly think that the fewer actions that a user has
> to perform, whether they by physical (e.g. clicking) or cognitive
> (e.g. remembering), then the more riskier and less safer the login
> process is from the point of view of security.  This does assume
> that the user has close to an accurate understanding of the action
> she is about to perform.  The latter is a lot more difficult to
> effect then most with geek training believe.
>
> To reiterate, the main point here is that fewer user actions
> imply less safety.

Interesting logic. Does that mean that more actions is more safety?  
Would the security of each action not be relevant?

Is "asasasasasasasasasasasasasasasasasas" a better password then  
"6@h." because there are more keystrokes?

If you make the user jump through a bunch of hoops each time they  
authenticate, they strive to make their life simpler, not more secure.

Writing the really strong password on the sticky  right beside the  
monitor is a classic example.

-- Dick

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Eric Norman]

On Jun 27, 2008, at 2:30 PM, Dick Hardt wrote:

>
> On 27-Jun-08, at 12:25 PM, Eric Norman wrote:
>
>>
>> On Jun 27, 2008, at 9:25 AM, Dick Hardt wrote:
>>
>>> *if* the RP remembers the user's OpenID the first time they visit the
>>> site and the user only uses one OpenID on the site, then when the
>>> user
>>> returns, and if the RP autofills the OpenID in the form, then the
>>> user
>>> just has to click the submit button to login (assuming they have a
>>> valid session at their OP and their OP is configured to automatically
>>> login to that RP
>>>
>>> Lots of assumptions in this flow, definitely room for improvement.
>>>
>>> Question: do people think improving this is important?
>>
>> Well, I certainly think that the fewer actions that a user has
>> to perform, whether they by physical (e.g. clicking) or cognitive
>> (e.g. remembering), then the more riskier and less safer the login
>> process is from the point of view of security.  This does assume
>> that the user has close to an accurate understanding of the action
>> she is about to perform.  The latter is a lot more difficult to
>> effect then most with geek training believe.
>>
>> To reiterate, the main point here is that fewer user actions
>> imply less safety.
>
> Interesting logic. Does that mean that more actions is more safety?

In general, yes. although it does depend on the difficulty that a
user has either comprehending or performing the actions.

Consider the holy triumvirate that folks like to quote about
"something you ...".  Translate each one as "something you have
to do" (an action, e.g. remember something;  pull out and show
something).  Then more actions are really just another way of
having multi-factor; that's the point of view I have.

>  Would the security of each action not be relevant?

I can't answer that unless I have a metric to measure "security".

> Is "asasasasasasasasasasasasasasasasasas" a better password then
> "6@h." because there are more keystrokes?

Sure it is -- lots better, but not directly because of the keystrokes.
Is there some metric that says otherwise?

> If you make the user jump through a bunch of hoops each time they
> authenticate, they strive to make their life simpler, not more secure.

Methinks user will strive to make their life easier regardless.
The trick is to find a balance between easy living and security.
And don't assume that I mean to imply automation and transparency
are always the answer.  Sometimes they're appropriate, sometimes
not.  That's part of the balance problem.

Eric Norman

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

fre, 27 06 2008 kl. 20:20 -0500, skrev Eric Norman:
>
> > Is "asasasasasasasasasasasasasasasasasas" a better password then
> > "6@h." because there are more keystrokes?
>
> Sure it is -- lots better, but not directly because of the keystrokes.
> Is there some metric that says otherwise?

There is, but a better example is:

Is "polyester" a better password than "6@h."?

The user has to perform more than twice as many keystroke actions! Yet a
simple dictionary attack will crack the former while the latter must be
brute-forced character-by-character.

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

Sorry, missed one point.

fre, 27 06 2008 kl. 20:20 -0500, skrev Eric Norman:
> Consider the holy triumvirate that folks like to quote about
> "something you ...".  Translate each one as "something you have
> to do" (an action, e.g. remember something;  pull out and show
> something).  Then more actions are really just another way of
> having multi-factor; that's the point of view I have.

I always thought multi-factor felt a little vacuous, because it depends
of the security of the individual factors (i.e. "chain as strong as
weakest link" has higher precedence), but I don't think that abstraction
is in accordance with multi-factor security at all - its quite the
opposite.

The idea behind multi-factor security is that you use tokens from
different "domains" (knowledge, physical possession, certified
credentials), on the premise that its harder to compromise several
"domains" than just a single one. That's not the same as saying that
multiple tokens from within the _same_ domain are more secure, because
once you're inside you tend to have access to it all.

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>once you're inside you tend to have access to it all.

As a matter of policy, the passwords that have the greatest need to
be secure ought to be more difficult to remember - they can't be
written down or frequently used (the latter nullifies this and the
latter weakens it). As a general principle, any password that
requires you to sit there for a few minutes just to figure out what
it was, has greater security.

The same could apply to other areas. Take the physical token you
carry around with you all the time, versus the one that is locked up
in the vault at a local bank - someone mugs you for the everyday
token and doesn't get the ability to make any severe changes.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

Well, 'policy' and 'practice' are two different things.

fre, 27 06 2008 kl. 20:28 -0700, skrev SitG Admin:

> >once you're inside you tend to have access to it all.
>
> As a matter of policy, the passwords that have the greatest need to
> be secure ought to be more difficult to remember - they can't be
> written down or frequently used (the latter nullifies this and the
> latter weakens it). As a general principle, any password that
> requires you to sit there for a few minutes just to figure out what
> it was, has greater security.
>
> The same could apply to other areas. Take the physical token you
> carry around with you all the time, versus the one that is locked up
> in the vault at a local bank - someone mugs you for the everyday
> token and doesn't get the ability to make any severe changes.
>
> -Shade
>

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>Well, 'policy' and 'practice' are two different things.

True, so there's the "tendency" you spoke of - but it could still be
more secure if it didn't rely on the user to put policy into
practice. It's getting there that is the hard part - never
underestimate the ability of a user to screw up any measures taken to
protect them ;)

(This, if anything, is a justification for Trusted Computing's "the
user may not have access to their own key".)

I took the "user actions" Eric Norman spoke of to be *types* of user
action - such as checking a URL visually (to make sure it's their
OP), typing in their Identity, and clicking a button (though I don't
readily see how this would be a security measure). Another question
is whether actions that Firefox takes on behalf of the user (such as
filling in a field or notifying the user that this site's certificate
doesn't match) can be treated as "user actions".

How about requiring the user to authenticate using multiple *literal*
"domains"? Any one OP normally, but 2 or more in succession (that
have previously been used) to make changes?

At the far extreme end of the spectrum, the login process is
initiated for any site the user visits and completed automatically
with all requested fields.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Eric Norman]

On Jun 27, 2008, at 10:54 PM, SitG Admin wrote:
>

> I took the "user actions" Eric Norman spoke of to be *types* of user
> action - such as checking a URL visually (to make sure it's their
> OP), typing in their Identity, and clicking a button (though I don't
> readily see how this would be a security measure).

Clicking on a button typically represents a decision on the
part of the user.  E.g. do I want this process to continue?
This is one of the cognitive actions being asked of the
user and it's usually related to security.

>  Another question
> is whether actions that Firefox takes on behalf of the user (such as
> filling in a field or notifying the user that this site's certificate
> doesn't match) can be treated as "user actions".

Just because the information received on the other end
appears to have been constructed by the user doesn't mean
that it actually was.  The user actions I'm talking about
require that the user decides to perform some task.

In the case of the certificate warning, the user decision
is whether to continue or not.

> How about requiring the user to authenticate using multiple *literal*
> "domains"? Any one OP normally, but 2 or more in succession (that
> have previously been used) to make changes?

I would like such a feature.  I doubt if any of my sisters
would think of it as anything other than harassment, though.

> At the far extreme end of the spectrum, the login process is
> initiated for any site the user visits and completed automatically
> with all requested fields.

True enough, and I'm arguing that what's described above is
at the low extreme end of the security spectrum.

Eric Norman

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>Clicking on a button typically represents a decision on the
>part of the user.  E.g. do I want this process to continue?
>This is one of the cognitive actions being asked of the
>user and it's usually related to security.

By the time you're typing in the URI, you've mentally committed to
initiating a login action. Doing something else with your hands
(orienting a pointer on a web-button and clicking the mouse-button)
doesn't really count as another cognitive action then; good luck
training users to treat these as separate endeavors which require
different analysis.

Of course, it *would* become useful if the URI was automatically
filled in for you, but then you lose the typing action (lose one,
gain one). I can see where the auto-complete feature would be
desirable for SSO, but it's not a "convenience" I care for (in fact I
find it bloody INconvenient, on par with Word's auto-correct of
spelling and grammar - what appears on screen should be exactly what
I'm typing).

I think users that know about keyboard shortcuts (aware they can just
hit "return" after entering the data) will take care of it all from
the keyboard, instead of interrupting their end of the process to
move hand to mouse, move pointer on screen, and click.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Dick Hardt]

On 28-Jun-08, at 12:31 PM, SitG Admin wrote:
>
> I think users that know about keyboard shortcuts (aware they can just
> hit "return" after entering the data) will take care of it all from
> the keyboard, instead of interrupting their end of the process to
> move hand to mouse, move pointer on screen, and click.

I think the average user on the web is more likely  to have their hand  
on the mouse then on the keyboard.

There is a strong correlation between the web taking off and the  
availability of graphical browsers that let users click on a link in  
one document and get another document.

Remember Amazon's one-click patent? It was not the one-keystrocke-
patent. :)

I think a solution that lets the users just click on something to  
proceed will be preferable to a keyboard shortcut.

- Dick

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Leon Kuunders]

Nice discussion, but

Dick Hardt wrote:

> Presuming one of our objectives is to simplify the user experience of  
> logging into websites. From the users point of view, they  want to  
> login once and be done with it. This is the user view of SSO.

Methinks this premise is more likely to be: "a user would like to offer it's
credentials once and be done with it."
Users do not want to login. Really, they don't.

Therefore you can measure the success of SSO by counting the dissapearing
login "buttons" or "links" on websites who do offer user centric (profiling)
services.
"Click to proceed", yes, "Login" no.

Regards, Leon


_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>Users do not want to login. Really, they don't.
>
>Therefore you can measure the success of SSO by counting the dissapearing
>login "buttons" or "links" on websites who do offer user centric (profiling)
>services.

A vital question here, then, is whether the user values privacy
enough to forgo this level of convenience. Short of opting to
automatically grant all RP requests (and never prompt user for
re-authentication to the OP - it can still expire, just don't bother
the *user* with renewing it), there is no way to "intelligently"
practice selective login for the user.

>"Click to proceed", yes,

There shouldn't even be that, though. Just go to the site and see the
page. No matter how much you abstract the process of authenticating,
if they have to take steps to have the service recognize them then
it's a login.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Hans Granqvist]

>>"Click to proceed", yes,
>
> There shouldn't even be that, though. Just go to the site and see the
> page. No matter how much you abstract the process of authenticating,
> if they have to take steps to have the service recognize them then
> it's a login.

The entire idea of logging in is a bit of an anachronism. :)

The user should offer to automatically identify and authenticate, and
the RP acts on the credentials if it wants to.

There seems to be a way to do this with OpenID. You need to tweak it
just a bit. I wrote up my thoughts about this a while back:

http://commented.org/blog/2008/1/3/continuous-openid.html

Hans
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general