On 29 December 2010 04:13, Dmitriy Shabanov <shabanovd@gmail.com> wrote:
On Tue, 2010-12-28 at 22:02 +0000, Thomas White wrote:
> Dmitriy,
> I run a build from the trunk with OpenID enabled. Accessing
> localhost:8080/exist/openid ends with an error about a missing
> file from a missing directory "webapp\openid\login.xql". Where do I
> get this directory from?
> If I open localhost:8080/exist/administration I get a login screen
> with a number of OpenID providers but as soon as I click on any of
> then I get an error "Message:OpenID realm wasn't initialized."

You should add <realm id="OpenID"/> to /db/system/security/config.xml
Which are the acceptable OpenID here? 
Where is the list of the available OpenIDs?
How do I add a new realm. I am particularly interested in adding Facebook id.
BTW it seams to me we need a function that adds an OpenID realm. It will be both: 1) much safer then editing an important system XML file; 2) It will allow us to add new OpenIDs from a web user interface in run time.
  $name as xs:string,
  $url as xs:string,
  $label as xs:string,
  $icon as element(icon)
) as element(realm)
A typical call will look like:
  'Enter your AOL screenname.',
  <icon height="32" width="64" >xmldb:exist:///db/openids/icons/aol.jpg</icon>
it will return
  <label>Enter your AOL screenname</label>
   <icon height="32" width="64" >xmldb:exist:///db/openids/icons/aol.jpg</icon>

> Apart from these errors I have some other questions:
>  1. How do I configure the list of available OpenID providers? Say I
> want to add Facebook login.
>  2. How do I update the user interface to reflect that?

Both controlled by UI widget, dig administration login form.
Looking at the UI widget it seams there is not relation between the available OpenID realms and the IDs displayed on the screen.
We need a function list-openid-realms() that returns realm elements with the format described in add-openid-realm() example. Once we have list-openid-realms()  I am going to modify the widget code to display only the registered OpenID realms.
>  3. I do remember some time ago there was an discussion that at that
> time that these is a need of special XQuery to persist OpenID details
> into the db. Do we still need this file? If yes where do I take this
> file from?

Guess, not.

>  4. If I have a user that has logged in with a generic eXist user name
> first and later he decided to login with a number of OpenIDs, how do I
> know he is the same user when he loggs in with any of the OpenIDs or
> with eXist credentials. In other words how do I associate a generic
> eXist user with a number of OpenIDs?

You can't, only group can help here.
This actually is a big problem. It neither logical nor practical.
The current implementation of groups is so limited and restrictive (because we do not support a group of groups). If we use a group just to associate a number of OpenIDs to a native eXist user account there is nothing left to use on a application level for other group membership. 
What is important is WHO the user is, not HOW he was authenticated.  It is like in the real life - a single person can have many IDs like passport, driving licence (sometimes even with different names) etc, but we are interested of who he is, not which document was used to enter the building.
The worse side effect of this design I can see is that any existing application that wants to offer OpenID as well, has to go through a major user management code update because every existing user now will appear as a new user every time when he logs in with a different OpenID. This is just not going to happen.
We do need to have a way to uniquely and consistently identify and refer to an user,  regardless of how he has been authenticated.
The new security design should take this into account and provide an API that makes user's identification transparent to the applications build on eXist and allow to add more ways to authenticate an user, without expecting applications to change user management every time when new authentication methods is added instead of creating yet another user's split personality (pun intended :-).

> It seams  the core OpenID  functionality is there but unfortunately it
> does not work out of the box. It would be very helpful if we have a
> working example as part of the build which we can try, study and
> extend in our own projects.

You did promise to write one :-)
I will be glad to do it when I am able to reproduce consistently working OpenID functionality.
Hopefully with the additional functions suggested in this email.


Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007