Article: Using OpenID

Discussions

News: Article: Using OpenID

  1. Article: Using OpenID (14 messages)

    OpenID is an open, decentralized, open-source framework for user-centric digital identity (SSO). Think about all the accounts you have online: blogs, wikis, photo galleries, todo lists. The list is endless. Even simple tasks such as leaving comments on someone else's blog may require you to register an account with that particular blogging system. This leaves you, as an end user, to set up and manage numerous accounts on each of these site. With OpenID, rather than managing all these disparate accounts individually, users can manage their identity via an authentication server. OpenID is the best effort and wide scale adoption by the Internet community to centralize on an authentication approach that users can actually use. It does the same things as existing protocols such as SAML, however the adoption of the protocol is slimmed down and easier to implement that existing approaches. The technology is easy to install, deploy and maintain. Anyone with basic programming skills can understand and deploy the technology with the new or existing web-application. This article explains what it is, how it works, and how you can integrate it into your applications.

    Threaded Messages (14)

  2. Re: Article: Using OpenID[ Go to top ]

    I doubt Yahoo and large audience websites, especially ecommerce ones would use OpenID: they get some valuable informations from the user profile, like sex, birth date, if not your preferred shoes color. Note OpenID is a way for new website to easily get new users, since subscription pages are a classic way to make people go away. From a confidential point of view, OpenID let all your preferred websites about your login/password... Having a single and centralized identity does't give strong guarantees about confidentiality and hence make this identity unuseful for real authentication (remember : don't give your password to anybody...and to any website !). I won't use it on my website, unless Yahoo or google would use it :-) - Note i've not mentioned MSN. Why not ?
  3. Re: Article: Using OpenID[ Go to top ]

    I doubt Yahoo and large audience websites, especially ecommerce ones would use OpenID: they get some valuable informations from the user profile, like sex, birth date, if not your preferred shoes color.
    Yahoo might want to be an OpenId server. This means they get eyeballs even when the user isn't even going to Yahoo.
    Note OpenID is a way for new website to easily get new users, since subscription pages are a classic way to make people go away.

    From a confidential point of view, OpenID let all your preferred websites about your login/password...
    Huh? Are you saying the OpenId server gives them your password? If that's what you think you are very mistaken about how this works.
    Having a single and centralized identity does't give strong guarantees about confidentiality and hence make this identity unuseful for real authentication
    Again huh?
  4. Re: Article: Using OpenID[ Go to top ]

    Having a single and centralized identity does't give strong guarantees about confidentiality and hence make this identity unuseful for real authentication


    Again huh?
    Does it really matter if a server has your authentication history? In fact, as a corporation I may need this data for auditing reasons. Besides, this type of data is kept on you already. Your phone company, ISP, credit card, etc, record your usage. One of the things I like about my credit card company is they send me yearly summaries of where/how I have spent my money. Cheers, Justen Stepka http://www.jstepka.name/blog/
  5. Re: Article: Using OpenID[ Go to top ]

    My comment is about identity theft : doesn't openID open new doors for phishing (look your nice authentication server page ... which is in fact a phishing one) or CSRF attacks ?
  6. Re: Article: Using OpenID[ Go to top ]

    From a confidential point of view, OpenID let all your preferred websites about your login/password...
    Ummmmm... no?
    (remember : don't give your password to anybody...and to any website !)
    Remember: Try to understand stuff before you comment on it.
    Note i've not mentioned MSN. Why not ?
    Because you're a teacher an you like to ask pointless questions. Hoogla Boogla
  7. Re: Article: Using OpenID[ Go to top ]

    Nice Article. But seems application (relying) has to add bunch of code to implement it, Can't it be simple like adding Google Map. Is it not possible for OpenID servers or any third party to hide its complicity and implement it as a webservice or web module (gadget, or anything like that) so client application has to just add few line of html code and application will be OpenID compliant. I understand OpenID server can be different for different user and adding any third-party in between can be problem for security but if trusted organization host these kind of service, It will be awesome for new small level site developer.. Just a thought!!
  8. But seems application (relying) has to add bunch of code to implement it, Can't it be simple like adding Google Map. Is it not possible for OpenID servers or any third party to hide its complicity and implement it as a webservice or web module (gadget, or anything like that) so client application has to just add few line of html code and application will be OpenID compliant.
    There is a Java library called OpenId4Java that makes things very easy. Look at http://code.google.com/p/openid4java/wiki/QuickStart and you see that it only takes some lines of code to make it work. Stephan Albers
  9. Re: Article: Using OpenID[ Go to top ]

    I doubt Yahoo and large audience websites, especially ecommerce ones would use OpenID: they get some valuable informations from the user profile, like sex, birth date, if not your preferred shoes color.
    AOL is working on OpenID support and they already have working OpenID URI for their users. The list of open source applications supporting OpenId is also very impressive. Stephan Albers
  10. Hierarchical?[ Go to top ]

    Is it possible to make this in some way hierarchical? For example, a family (a similar example could work for companies) could have a domain and approve all IDs on that domain to authenticate for any requests, but stop children within that domain authenticating to any requests from sites not on a particular list. So firstname.familyname.domain.com would be unrestricted (for Mum and Dad), but firstname.kids.familyname.domain.com would be restricted by a specification within the familyname ID group. As I mentioned, somethink similar to this could be useful in organisations as well. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com
  11. Re: Hierarchical?[ Go to top ]

    Is it possible to make this in some way hierarchical?

    For example, a family (a similar example could work for companies) could have a domain and approve all IDs on that domain to authenticate for any requests, but stop children within that domain authenticating to any requests from sites not on a particular list.

    So firstname.familyname.domain.com would be unrestricted (for Mum and Dad), but firstname.kids.familyname.domain.com would be restricted by a specification within the familyname ID group. As I mentioned, somethink similar to this could be useful in organisations as well.

    Cheers,
    Ashley.

    --
    Ashley Aitken
    Perth, Western Australia
    mrhatken at mac dot com
    It would all depend on your server implementation. With Crowd we are doing whitelist and blacklist. This way you can say, "only allow these web-apps to authenticate with me" or "do not allow this server". Cheers, Justen Stepka http://www.jstepka.name/blog/
  12. HTTP redirect?[ Go to top ]

    The 2.0 Draft says "....This means an end user can prove their Identity to a Relying Party without having to leave their current Web page." but the openid.net homepage says "...To login to an OpenID-enabled website (even one you've never been to before), just type your OpenID URI. The website will then redirect you to your OpenID Provider to login using whatever credentials it requires. Once authenticated, your OpenID provider will send you back to the website..." I would be interested in this if there was no reliance on a HTTP redirect for authentication.
  13. Re: HTTP redirect?[ Go to top ]

    The 2.0 Draft says "....This means an end user can prove their Identity to a Relying Party without having to leave their current Web page."

    but the openid.net homepage says "...To login to an OpenID-enabled website (even one you've never been to before), just type your OpenID URI. The website will then redirect you to your OpenID Provider to login using whatever credentials it requires. Once authenticated, your OpenID provider will send you back to the website..."

    I would be interested in this if there was no reliance on a HTTP redirect for authentication.
    The question then is how the end user know that they were providing their authentication to the site they trust. I think there are some solutions but because web browsers are the defacto standard for web applications, solutions are limited in this regard. One thing I was wondering about is if I login to a OpenID authentication site and someone else types in my authentication URL into a site, do they get in, or does my OpenId provider ask me in real-time whether I am trying to access that site, or does it use something like my IP to verify that it is actually me?
  14. Re: HTTP redirect?[ Go to top ]

    One thing I was wondering about is if I login to a OpenID authentication site and someone else types in my authentication URL into a site, do they get in, or does my OpenId provider ask me in real-time whether I am trying to access that site, or does it use something like my IP to verify that it is actually me?
    The standard workflow adopted by OpenID providers is that once an external site requests authentication of a particular OpenID identifier, it prompts the user to log in to the OpenID provider. If the user has a logged-in session with the OpenID provider, the provider then asks asks the user: "Would you like to allow authentication to this external site: http://example.com ?". The standard approach is to "allow", "deny" or "allow always" authentication for the external site. Thus the server can give the end-user complete control over who is allowed to verify authentication.
  15. Re: HTTP redirect?[ Go to top ]

    "...To login to an OpenID-enabled website (even one you've never been to before), just type your OpenID URI. The website will then redirect you to your OpenID Provider to login using whatever credentials it requires. Once authenticated, your OpenID provider will send you back to the website..."

    I would be interested in this if there was no reliance on a HTTP redirect for authentication.
    Requests for authentication are made by the external site to the OpenID provider via HTTP redirects. This means that the actual HTTP request for authentication originates from the end-user's browser. This is sweet because it allows your OpenID provider to keep track of the fact that you are already authenticated with your provider (via cookies specific to the OpenID provider's domain). Thus you won't have to sign in again to your provider for the duration of the session. Also, if you visit an external site and try to login via OpenID, while not authenticated to your OpenID provider, the HTTP redirect can be used by the OpenID provider to prompt you for authentication. If instead, the external site directly requested authentication from the OpenID provider (without redirecting through the end-user's browser), the user would need to provide their authentication details to the external site!
    The 2.0 Draft says "....This means an end user can prove their Identity to a Relying Party without having to leave their current Web page."
    The external site may request authentication to the OpenID provider via a special "check-immediate" mode, which asks the OpenID provider to immediately authenticate or deny authentication of a particular user. This mode is designed for AJAX style interfaces where the site merely wants to know if the user is authenticated or not, without taking the user to a different page.