Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
The Internet Networking Security

OpenID - Open Source Single-SignOn 209

Nurgled writes "Danga Interactive, who created LiveJournal and memcached, is working on a new decentralized single-signon system called OpenID. Similar in principle to Six Apart's TypeKey or MSN Passport, OpenID will allow you to assert a single identity to any OpenID-supporting site. The difference here is that there is no central authenticating server: anyone can run one, and Danga's reference implementations will be open-source. The site you are authenticating with never sees your username or password, just a one-time token. You can read the initial announcement on LiveJournal, though some details have changed since that post, so be sure to read the information on the official site."
This discussion has been archived. No new comments can be posted.

OpenID - Open Source Single-SignOn

Comments Filter:
  • by Doctor Crumb ( 737936 ) on Thursday May 19, 2005 @12:55PM (#12579875) Homepage
    You are confusing Authentication with Authorisation. Authentication is proving that You Are Who You Say You Are, i.e. the purpose of systems like OpenID. Your cookies/etc would be involved with Authorisation instead, deciding what that person is allowed to do on your site.

    Of course, if a central signon system doesn't work for you, then don't use it.
  • Re:will this work? (Score:3, Informative)

    by Doctor Crumb ( 737936 ) on Thursday May 19, 2005 @12:59PM (#12579923) Homepage
    If you had RTFA, you would know that this is not a
    Single Signon. It is a Set Of Single Signons. You can have as many identities as you want. The difference is that without something like this, you are forced to have one identity per site, or one Passport ID. With an openID implementation, you can have any number of accounts as fit your needs. One potentially useful scheme is to have one signon for blogs and news sites, and then individual identities for each bank/etc.
  • LID (Score:2, Informative)

    by ibku ( 735269 ) on Thursday May 19, 2005 @01:06PM (#12580002)
    http://lid.netmesh.org/ [netmesh.org] - I've heard good things about LID, and it supports SSO.
  • by Anonymous Coward on Thursday May 19, 2005 @01:20PM (#12580160)
    This is a problem that already has a solution in production. Using pubcookie [pubcookie.org] for the single sign on, and Shibboleth [internet2.edu] for the distributed trust relationships.
  • Re:Bad idea (Score:3, Informative)

    by Suppafly ( 179830 ) <slashdot@sup p a f l y .net> on Thursday May 19, 2005 @01:32PM (#12580314)
    See what happens when you don't read the article, you end up not understanding what it's about and then you make stupid comments.
  • by scaldef ( 704048 ) on Thursday May 19, 2005 @01:45PM (#12580461)
    The problem with this is that really security conscious sites (like your bank) won't go for it. The reason is precisely the bit you put in italics. Financial institutions want, as much as possible, to authenticate actual people, not computer programs.
  • by Paul Crowley ( 837 ) on Thursday May 19, 2005 @01:50PM (#12580506) Homepage Journal
    I don't think RSA is overall more trusted than DSA, and I certainly don't see a way in which it's more flexible for this application. It was designed only to do signatures, but that's fine, since only signatures are needed here.

    When you say "leaking bits", you're probably thinking of subliminal channels, and you're referring to some rather out-of-date information in Applied Cryptography. It's now established that all secure signature schemes have subliminal channels; they have to be probabalistic for the security proofs to work, and that's enough to give a "low-bandwidth" channel for anyone who doesn't know the signing key, or a "high-bandwidth" chanel for those who do.

    DSA is a perfectly good choice here.
  • by Alioth ( 221270 ) <no@spam> on Thursday May 19, 2005 @02:06PM (#12580739) Journal
    Because if you log onto a foreign web site, it says, "Ah, this person is giving me an id which is stored on another server. Let me ask that other server if this person is known to them". If the other server knows this, it returns a token so now you know that the other server authenticated. (You can then associate things with this token for when the user next visits your server).

    So basically, if you're logging onto the web site where you are registered, it simply makes a local call to a local database. if you provide an ID registered at another server, instead of the webserver looking in its local database of IDs, it asks the remote server if it knows the user. That way the user doesn't have to register with your site, too.
  • Wow. (Score:3, Informative)

    by yitzhak ( 720512 ) on Thursday May 19, 2005 @02:07PM (#12580750) Homepage
    I mean, I shouldn't be surprised, but I am. It seems liek 90% of the people commenting didn't RTFA, or didn't have their brains installed at the time. This isn't a secure banking system - it is, as one person pointed out, probably better described as OpenHandle. You sign in ONCE, and from that site, you tell it which other sites can authenticate from your identity site. Then, these sites know who you are. They don't get your password, or anything, they just get a temporary key to verify that you're you. Any site can fake it, that's not the point. The point is that you have participating sites where you would want to now have to sign in every time you want to comment. It helps prevent lock-in to blogs etc - imagine, for example, you sign in to slashdot, and then you can use the same handle without having to create accounts and sign in at other blogging services. THAT's the idea. It's not a trust net, or a passport-like system, it's just so that sites that want to play by the rules can provide people with a convenient way to identify themselves. That's ALL.
  • by ProgressiveCynic ( 624271 ) on Thursday May 19, 2005 @02:30PM (#12581014) Homepage
    Call me perverse, but anytime someone tells me not to argue a point I just can't resist. ]=D

    SAML has been widely adopted, just not in the use case you're imagining. For B2B scenarios it is actually taking off quite well, and the US federal government is standardizing on it. [cio.gov]

    Now, it hasn't caught on in the world of consumer focused web sites, which is understandable given the architecture - no consumer authenticates at an authority before accessing sites, so it only makes sense for co-ordination between business partners who are providing services to the same users right now. Until a commercial site becomes an identity authority accepted by most consumer sites this will continue to be true. LiveJournal could have attempted to become this authority using existing standards far more easily than tackling the creation of new protocols and implementation platforms at the same time they try to build the business structure. But like most of us, they appear eager to reinvent the wheel.

    I find it interesting though that on the one hand every techy's complaint about Passport et al was the monopolistic, centralized model, with all the very appropriate concerns about putting your eggs in one basket - and then when a decentralized model comes along, people wonder why it only catches on in small pockets. What exactly did you think decentralized meant? If you truly want a global SSO mechanism then you are asking for an identity monopoly. If you want different identity providers, you are going to have to deal with trust issues from each provider to whichever resources you want to access. This is a business problem, not a techical one. The standards and technologies to implement whatever world we want to create are there, we just need to figure out what we are really asking for.

  • by Hurderos ( 859412 ) on Thursday May 19, 2005 @05:16PM (#12582913) Homepage
    I do wish the authors success but OpenID is simply another protocol for asserting identity information. What is fundamentally missing, especially in OSS, is a mechanism for implementing identity. In truth implementing identity is something that is also missing in the plethora of commercial products which are seeking to provide solutions in this space.

    Globus/GRID, Shibboleth, PubCookie, LID and a legion of others are already implementing mechanisms for making assertions about an identity. The fundamental problem with implementing any of these technologies are the back-end systems for implementing and protecting identity and a manageable system for tracking differential acesss (authorization) at a high level of granularity.

    The Open-Source community is currently lacking any respectable effort in this arena. All the basic pieces are there with LDAP, Kerberos, SAML and a host of other technologies. What is required is a coherent framework which implements all these technologies in a manageable package of infra-structure. It will be where the real war for control of information delivery gets won or lost for OSS technologies over the remainder of the decade.

    As I noted in the first paragraph what is fundamentally lacking across the spectrum, commercial or otherwise, is a fundamental definition of identity. Its interesting to see that a couple of other posters have noted this as well. Our Hurderos Project is trying to address that with an OSS solution in an attempt to turn the tide of everyone inventing their own solution.

    Getting that type of basic infra-structure laid down is key to unlocking an entirely new generation of application and information delivery architectures. It is also fundamental to addressing the intrinsic problem with federated or distributed identity systems which is the very real and very thorny problem of target sites asserting authorization over remotely authenticated identities.

    In the brave new world of highly distributed information delivery systems with a mobile consumption (client) base the only important thing is 'who you are and what do you have access rights to'. He who controls that will control everything.
  • by More Trouble ( 211162 ) on Thursday May 19, 2005 @05:40PM (#12583219)
    For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on.

    I'm one of the authors of CoSign [weblogin.org], which is a "traditional" Web Single Sign-on system. Really, SSO is explicitly not very useful in a small environment. SSOs are particularly useful in medium to large enterprise environments, primarily because identity needs to be tracked across many different application -- for provisioning, auditing, authorization, etc. An SSO reduces the security exposure in this environment, because the user's credentials are only used during initial sign-on, and not presented to each service.

    OpenID's goals are somewhat similar, in that a form of the user's ID is made available to visited servers, without exposing information that might be important to the user. OpenID could be a big hit on the Internet if sites like GMail, Hotmail, and other enterprise environments that do strong authentication were to act as OpenID "homesites". Obviously, GMail isn't going to trust Livejournal to grant a user access to their mail. But LJ might trust GMail for a user to leave a comment.

    :w
  • Re:Why DSA? (Score:3, Informative)

    by nickovs ( 115935 ) on Thursday May 19, 2005 @06:33PM (#12583687)
    I'm surprised OpenID is using DSA though - AFAIK RSA (now that it's patent free) is a superior, more trusted and flexible algorithm.

    As a professional cryptographer I certainly don't think that DSA is in any way inferior for the task in hand. It is however superior in one significant way: if you use a 1024 bit key then the RSA signature is 1024 bits, which takes 171 bytes to base64 code, while the DSA signature only takes up 54 bytes.

"I've seen it. It's rubbish." -- Marvin the Paranoid Android

Working...