[OpenID] OpenID + Government
Troy Benjegerdes
hozer at hozed.org
Wed Aug 12 14:25:22 UTC 2009
Openid-ldap confuses *Authentication* with *Authorization*.
OpenID is primarily about a user being able to *Authenticate* once to some
identity provider, and then have the identify provider authenticate on
behalf of the user to many different web based sites and resources.
So I suppose it seems a naive user would wonder why *Authorization*
even matters.
But any reasonable implementation of an IdP requires non-trival *Authorization*
of whether or not the IdP is to disclose information about a particular
authenticated user.
So based on what I've seen so far, there are a couple of toy open source
IdP implementations, and several web application packages with nice OpenID
integration that re-use the existing web application's authentication
and authorization schemes.
But nothing I've seen so far provides a functional, standalone IdP with clear
separation of these two roles, and I will argue that lack of such a thing
is the fundamental barrier behind deployment of the 'open web' vision, and
not any sort of barrier from government standards.
My dedication to the cause is unfortunately funding-constrained, and
mostly limited to posting on this mailing list, and trying to encourage what I
think is a reasonable architecture that I would be able to use. Although,
if anyone has any ideas how to change that constraint, I would love to hear
from them directly.
On Tue, Aug 11, 2009 at 04:20:47PM -0700, Chris Messina wrote:
> I don't know if this is relevant to your question, but I found these
> resources:
> http://www.openid-ldap.org/
> http://blog.loftninjas.org/2009/08/10/using-openid-ldap-as-an-openid-provider/
>
> As for running your own OpenID
> provider ? I simply use the WordPress OpenID plugin. It currently does
> not integrate with stronger authentication services, but if you were
> dedicated to the cause, could probably make it happen.
>
> Chris
>
> On Tue, Aug 11, 2009 at 11:46 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
>
> > Bonus points if the implementation can store all per-user state in
> > fields in the users's LDAP entries, hopefully allowing the server
> > to be stateless, and mitigating security aspects by depending on
> > Kerberos and LDAP authentication and authorization for all security
> > critical information.
> >
>
More information about the general
mailing list