-------- Original Message --------
Subject: Re: PHPOKI and Moodle?
Date: Wed, 03 Nov 2004 19:06:14 -0500
From: Adam Franco <afranco@middlebury.edu>
To: Mike Franks <franks@ssc.ucla.edu>
CC: Gabe Schine <gschine@middlebury.edu>, Alex Chapin <achapin@middlebury.edu>
> So now we want to try using a full Moodle install and tie it into the campus authentication and ClassWeb and since we're going to do the work anyway, does trying to connect it with PHPOKI make sense?
Mike, as a caveat my initial guess is that it would be more work to do the interfacing via the Authentication OSID than directly. However, there have not been many implementations of the OSIDs yet, and your integration project could be very useful to you (as well as others) as to the practicality of implementing the OSIDs on both side of the integration layer.
As to what would be involved in such a project, here is a guess:
Make an implementation of the Authentication OSID that talks to your campus authentication.
Make a Moodle authentication module/function/etc (or however Moodle authenticates) that talks OKI Authentication syntax.
Step 1 above is probably the more challenging step, though the benefit is gained by only having to write that side of the pairing once and it can be used for any future integration projects. Our Harmoni framework provides an implementation of the Authentication OSID that makes use of another, internal authentication system.
For step 2 above, it seems that the general flow of this is that the client app will say something along the lines of:
/**
Authenticate via O.K.I. and return TRUE on success, FALSE on failure.
*
@return boolean
*/
function authenticateOKI() {
$isAuthenticated = FALSE;
// Load the authentication manager.
$authenticationManager =& ....;
// Check to see if we are already authenticated.
// This could be in another function.
$types =& $authenticationManager->getAuthenticationTypes();
while ($types->hasNext()) {
$type =& $types->next();
if ($authenticationManager->isAuthenticated($type)) {
$isAuthenticated = TRUE;
break;
}
}
// Authenticate via all methods until success.
if (!$isAuthenticated) {
$types =& $authenticationManager->getAuthenticationTypes();
while ($types->hasNext()) {
$type =& $types->next();
$authenticationManager->authenticateUser($type);
if ($authenticationManager->isAuthenticated($type)) {
$isAuthenticated = TRUE;
break;
}
}
}
return $isAuthenticated;
}
Well, except for the loading of the Auth.Manager, I think the above function should fulfill most of your needs on the client side.
Some last notes on the server side: It seems that it is up to the authenticateUser() function to prompt the user for appropriate authentication tokens, be they username/password, kerberos tickets, or otherwise. The nice part about this is that this setup isolates the client from having to know how to get the tickets from the user. The challenging part about this setup is that the authenticateUser() function has to be able to take control over the user's environment enough to prompt for and collect said tokens. In our Harmoni implementation we were able to accomplish this via HTTP authentication prompts, but HTTP auth has proven challenging when logging out as there is not a standard code to pass to the browser to get it to clear its HTTPauth cache. So far, other methods of prompting that we have tried have required a larger integration with the client environment, removing some of the utility of using the OSID. Maybe writing, then executing a Javascipt function, or page forwarding via header("Location: ...") would be able to provide the needed control.
Keep us updated on your success (or otherwise). I am going to post this thread in the Harmoni Forums for future referral. It may be easier if we continue its discussion there: http://sourceforge.net/forum/forum.php?forum_id=282908
Adam
--
Adam Franco
Educational Technology
Library and Info. Services
Middlebury College
Middlebury, VT 05753
(w) 802 443 2244
(c) 802 989 0702
AIM: AdamFranco
Mike Franks wrote:
> Adam,
>
> Thanks for posting about PHPOKI to both those threads. I particularly like what you wrote about the top-down/bottom-up argument.
>
> Here's my situation. We have need to use at least the quiz tool from Moodle, and I'm interested in the SCORM tool, and wiki, and maybe others. We overoptimistically thought we could extract the quiz tool logic and pull it into our ClassWeb (also PHP/MySQL) system, but had to settle for faking a class in a limited Moodle install and tying it together with ClassWeb and our campus authentication system.
>
> So now we want to try using a full Moodle install and tie it into the campus authentication and ClassWeb and since we're going to do the work anyway, does trying to connect it with PHPOKI make sense?
>
> Mike Franks email: franks@ssc.ucla.edu
> Social Sciences Computing phone: (310) 206-2109
> UCLA fax: (310) 825-4936
> homepage: http://www.sscnet.ucla.edu/ssc/franks/
> SSC Help Desk: 206-2821 help@ssc.ucla.edu
>
> On Wed, 3 Nov 2004, Adam Franco wrote:
>
>> Date: Wed, 03 Nov 2004 17:11:12 -0500
>> From: Adam Franco <afranco@middlebury.edu>
>> To: Mike Franks <franks@ssc.ucla.edu>
>> Cc: Gabe Schine <gschine@middlebury.edu>, Alex Chapin <achapin@middlebury.edu>
>> Subject: Re: PHPOKI and Moodle?
>>
>> Thanks for the info Mike,
>>
>> At this time we don't have any development plans involving Moodle, though were Moodle to either be able to expose its functionality via the O.K.I. OSIDs or act as a client of others' implementations, then foreseeably some inter-operation could be possible. In the thread that you linked to there was quite a bit of railing against the "top down" design of O.K.I.'s standards, but the alternative is, as you say, difficult to interface with. Actually, this thread:
>> http://moodle.org/mod/forum/discuss.php?d=1926
>> mentions our PHP OKI bindings and speaks a bit more intellegently about interoperability.
>>
>> Aside from maintaing the PHP OKI bindings, our own software is based around them for functional inter-operation with other systems (we hope) and should (after it is completed) use the IMS Content Packaging and/or SCORM standards for data interchange. Hopefully when the dust settles all these systems will be able to inter-operate around a few of these standards.
>>
>> Adam
>>
>> --
>>
>> Adam Franco
>>
>> Educational Technology
>> Library and Info. Services
>> Middlebury College
>> Middlebury, VT 05753
>>
>> (w) 802 443 2244
>> (c) 802 989 0702
>> AIM: AdamFranco
>>
>>
>> Mike Franks wrote:
>>
>>> Gabe,
>>>
>>> Doing a search on moodle oki I found this very interesting Moodle Developers thread. http://moodle.org/mod/forum/discuss.php?d=8958 You might want to tell them about your project. http://www.phpoki.org/
>>>
>>> Mike Franks email: franks@ssc.ucla.edu
>>> Social Sciences Computing phone: (310) 206-2109
>>> UCLA fax: (310) 825-4936
>>> homepage: http://www.sscnet.ucla.edu/ssc/franks/
>>> SSC Help Desk: 206-2821 help@ssc.ucla.edu
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's now 8 months later and we went the route of tying Moodle directly into our campus authentication system. While it worked, it is a lot of hacking and I wouldn't encourage others to do that.
Now, we're looking at Shibboleth as a way to more easily integrate other campus Moodles with the campus authentication service. Hearing that Moodle has a Shibboleth module inspired this.
But, now that UCLA is doing a SAKAI Pilot, and I went to the Baltimore conference last week, I'm wondering if PHPOKI will gain us anything in doing cross language work with SAKAI.
Mike Franks
Social Sciences Computing
UCLA
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for taking so long to get back to you, but I left for vacation just before your post.
First a little terminology explanation to make sure that we are all on the same page and for the benefit of any others who may stumble across this thread looking for similar info.
Open Knowledge Initiative's (O.K.I.) Open Service Interface Definitions (OSIDs) http://okiproject.org/
(From the website above) "The Open Knowledge Initiative develops specifications that describe how the components of an educational software environment communicate with each other and with other enterprise systems."
OKI in PHP http://www.phpoki.org/
Our group, Educational Technology at Middlebury College, are maintaining PHP bindings to the OSIDs. These bindings are PHP classes whose methods are unimplemented (each is just a "die()" statement), that are functionally equivalent to the Java OSID interfaces. To build PHP systems based around the OSIDs one could implement a service (such as Authentication) whose functionality is accessed via the classes and methods in the OSIDs. Concurrently/alternatively, one could write a client application that accesses a service via the classes and methods of the OSIDs and plug in any number of implementations of those services without re-writing how the client application calls the authentication system.
Harmoni Application Framework http://harmoni.sf.net
This is project of our group, Educational Technology at Middlebury College, to develop a PHP application framework based around the OSIDs for use in the second generation of our educational tools, specifically our Segue Collaborative Learning System (http://segue.sf.net). The Harmoni Application Framework contains our implementations of many of the OSIDs as well as a plethora of other tools and functionality to ease rapid application development in PHP.
Sakai http://www.sakaiproject.org/
(from the website above) "The Sakai Project is a community source software development effort to design, build and deploy a new Collaboration and Learning Environment (CLE) for higher education."
The Sakai Project includes the "Sakai application framework" and associated CMS tools, all in Java. I'm not sure of their current project status, but they will eventually be providing access to the various back-end services (such as Authentication, Authorization, and Repository) via implementations of the OSIDs.
Now that all of that is out of the way, on to how the O.K.I. OSIDs (and in particular the PHP version of them) may be able to help your efforts. I will assume that your client applications (Moodle and/or others) can call the necessary methods in the AuthN OSID to initiate the authentication sequence, something along the lines of the following pseudo-code:
(in a config somewhere, instantiate the appropriate AuthenticationManager object and an appropriate AuthenticationType object that identifies the particular authentication implementation to use as the OSID allows for multiple implementations to be accessed through a single AuthenticationManager)
// To log-in
if (!$authenticationManager->isUserAuthenticated($authenticationType)) {
$authenticationManager->authenticateUser($authenticationType);
}
$userId =& $authenticationManager->getUserId($authenticationType);
...
// To log-out
$authenticationManager->destroyAuthentication();
Below are several possible avenues that could be pursued.
Assuming that the current version of Sakai provides access to its authentication system via the AuthN OSID:
--- In PHP4 there is a module that allows Java classes to be instantiated from within a PHP script and have methods called on them as if they were PHP objects. This would probably only require some configuration to allow the appropriate Java-PHP object to be passed into your PHP script.
--- Alternatively, a simple PHP implementation of the Authentication OSID could be written that translates from the PHP object/method calls to the calls on the external Java Authentication implementation. I have not done much in the way of cross-language communication, but I am told that it can be "relatively" easy to get software to communicate across languages provided that there are equivalent APIs methods in both languages that do not require significant hacking around differing logical paradigms. Using the OSIDs as the common API could facilitate this process.
If the authentication system of Sakai (or your other campus authentication system) is not available via the AuthN OSID in any language, you could write a PHP (or Java) implementation of the AuthN OSID that queries your various authentication systems and then access this implementation from your client applications as mentioned above.
This avenue is basically adding an abstraction layer (your OSID implementation) between your client application and the underlying authentication system[s]. Going this route may prevent the need to re-write client applications as your university changes authentication systems as only your OSID implementation would need to change. As well, this could allow you to more easily plug in 3rd-party authentication implementations (such as the Harmoni ones to authenticate against LDAP, Banner, or a custom database), were that a desire.
In sum, using the O.K.I. interfaces in PHP may help your cross-language integration in that it provides a structure of parallel authentication methods that reduce the cross-language difficulty to simply making API-to-API calls across the language barrier rather than trying to make cross-language calls throughout your application.
I hope that this helps to answer your questions. Please post again if any particular area requires clarification.
Adam
--
Adam Franco
Educational Technology
Library and Info. Services
Middlebury College
Middlebury, VT 05753
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-------- Original Message --------
Subject: Re: PHPOKI and Moodle?
Date: Wed, 03 Nov 2004 19:06:14 -0500
From: Adam Franco <afranco@middlebury.edu>
To: Mike Franks <franks@ssc.ucla.edu>
CC: Gabe Schine <gschine@middlebury.edu>, Alex Chapin <achapin@middlebury.edu>
> So now we want to try using a full Moodle install and tie it into the campus authentication and ClassWeb and since we're going to do the work anyway, does trying to connect it with PHPOKI make sense?
Mike, as a caveat my initial guess is that it would be more work to do the interfacing via the Authentication OSID than directly. However, there have not been many implementations of the OSIDs yet, and your integration project could be very useful to you (as well as others) as to the practicality of implementing the OSIDs on both side of the integration layer.
As to what would be involved in such a project, here is a guess:
For reference, here is a link to the source of the Authentication OSID:
http://harmoni.sourceforge.net/harmoniDoc/phpdoc/osid.authentication/authentication.interface.php.html
as well as a like to the whole Harmoni Doc:
http://harmoni.sourceforge.net/harmoniDoc/phpdoc/
The above interface is found in the osid.authentication package.
Step 1 above is probably the more challenging step, though the benefit is gained by only having to write that side of the pairing once and it can be used for any future integration projects. Our Harmoni framework provides an implementation of the Authentication OSID that makes use of another, internal authentication system.
For step 2 above, it seems that the general flow of this is that the client app will say something along the lines of:
/**
*
@return boolean
*/
function authenticateOKI() {
$isAuthenticated = FALSE;
// Load the authentication manager.
$authenticationManager =& ....;
// Check to see if we are already authenticated.
// This could be in another function.
$types =& $authenticationManager->getAuthenticationTypes();
while ($types->hasNext()) {
$type =& $types->next();
if ($authenticationManager->isAuthenticated($type)) {
$isAuthenticated = TRUE;
break;
}
}
// Authenticate via all methods until success.
if (!$isAuthenticated) {
$types =& $authenticationManager->getAuthenticationTypes();
while ($types->hasNext()) {
$type =& $types->next();
$authenticationManager->authenticateUser($type);
if ($authenticationManager->isAuthenticated($type)) {
$isAuthenticated = TRUE;
break;
}
}
}
return $isAuthenticated;
}
Well, except for the loading of the Auth.Manager, I think the above function should fulfill most of your needs on the client side.
Some last notes on the server side: It seems that it is up to the authenticateUser() function to prompt the user for appropriate authentication tokens, be they username/password, kerberos tickets, or otherwise. The nice part about this is that this setup isolates the client from having to know how to get the tickets from the user. The challenging part about this setup is that the authenticateUser() function has to be able to take control over the user's environment enough to prompt for and collect said tokens. In our Harmoni implementation we were able to accomplish this via HTTP authentication prompts, but HTTP auth has proven challenging when logging out as there is not a standard code to pass to the browser to get it to clear its HTTPauth cache. So far, other methods of prompting that we have tried have required a larger integration with the client environment, removing some of the utility of using the OSID. Maybe writing, then executing a Javascipt function, or page forwarding via header("Location: ...") would be able to provide the needed control.
Keep us updated on your success (or otherwise). I am going to post this thread in the Harmoni Forums for future referral. It may be easier if we continue its discussion there:
http://sourceforge.net/forum/forum.php?forum_id=282908
Adam
--
Adam Franco
Educational Technology
Library and Info. Services
Middlebury College
Middlebury, VT 05753
(w) 802 443 2244
(c) 802 989 0702
AIM: AdamFranco
Mike Franks wrote:
> Adam,
>
> Thanks for posting about PHPOKI to both those threads. I particularly like what you wrote about the top-down/bottom-up argument.
>
> Here's my situation. We have need to use at least the quiz tool from Moodle, and I'm interested in the SCORM tool, and wiki, and maybe others. We overoptimistically thought we could extract the quiz tool logic and pull it into our ClassWeb (also PHP/MySQL) system, but had to settle for faking a class in a limited Moodle install and tying it together with ClassWeb and our campus authentication system.
>
> So now we want to try using a full Moodle install and tie it into the campus authentication and ClassWeb and since we're going to do the work anyway, does trying to connect it with PHPOKI make sense?
>
> Mike Franks email: franks@ssc.ucla.edu
> Social Sciences Computing phone: (310) 206-2109
> UCLA fax: (310) 825-4936
> homepage: http://www.sscnet.ucla.edu/ssc/franks/
> SSC Help Desk: 206-2821 help@ssc.ucla.edu
>
> On Wed, 3 Nov 2004, Adam Franco wrote:
>
>> Date: Wed, 03 Nov 2004 17:11:12 -0500
>> From: Adam Franco <afranco@middlebury.edu>
>> To: Mike Franks <franks@ssc.ucla.edu>
>> Cc: Gabe Schine <gschine@middlebury.edu>, Alex Chapin <achapin@middlebury.edu>
>> Subject: Re: PHPOKI and Moodle?
>>
>> Thanks for the info Mike,
>>
>> At this time we don't have any development plans involving Moodle, though were Moodle to either be able to expose its functionality via the O.K.I. OSIDs or act as a client of others' implementations, then foreseeably some inter-operation could be possible. In the thread that you linked to there was quite a bit of railing against the "top down" design of O.K.I.'s standards, but the alternative is, as you say, difficult to interface with. Actually, this thread:
>> http://moodle.org/mod/forum/discuss.php?d=1926
>> mentions our PHP OKI bindings and speaks a bit more intellegently about interoperability.
>>
>> Aside from maintaing the PHP OKI bindings, our own software is based around them for functional inter-operation with other systems (we hope) and should (after it is completed) use the IMS Content Packaging and/or SCORM standards for data interchange. Hopefully when the dust settles all these systems will be able to inter-operate around a few of these standards.
>>
>> Adam
>>
>> --
>>
>> Adam Franco
>>
>> Educational Technology
>> Library and Info. Services
>> Middlebury College
>> Middlebury, VT 05753
>>
>> (w) 802 443 2244
>> (c) 802 989 0702
>> AIM: AdamFranco
>>
>>
>> Mike Franks wrote:
>>
>>> Gabe,
>>>
>>> Doing a search on moodle oki I found this very interesting Moodle Developers thread. http://moodle.org/mod/forum/discuss.php?d=8958 You might want to tell them about your project. http://www.phpoki.org/
>>>
>>> Mike Franks email: franks@ssc.ucla.edu
>>> Social Sciences Computing phone: (310) 206-2109
>>> UCLA fax: (310) 825-4936
>>> homepage: http://www.sscnet.ucla.edu/ssc/franks/
>>> SSC Help Desk: 206-2821 help@ssc.ucla.edu
Adam,
It's now 8 months later and we went the route of tying Moodle directly into our campus authentication system. While it worked, it is a lot of hacking and I wouldn't encourage others to do that.
Now, we're looking at Shibboleth as a way to more easily integrate other campus Moodles with the campus authentication service. Hearing that Moodle has a Shibboleth module inspired this.
But, now that UCLA is doing a SAKAI Pilot, and I went to the Baltimore conference last week, I'm wondering if PHPOKI will gain us anything in doing cross language work with SAKAI.
Mike Franks
Social Sciences Computing
UCLA
Hello Mike,
Sorry for taking so long to get back to you, but I left for vacation just before your post.
First a little terminology explanation to make sure that we are all on the same page and for the benefit of any others who may stumble across this thread looking for similar info.
Open Knowledge Initiative's (O.K.I.) Open Service Interface Definitions (OSIDs)
http://okiproject.org/
(From the website above) "The Open Knowledge Initiative develops specifications that describe how the components of an educational software environment communicate with each other and with other enterprise systems."
OKI in PHP
http://www.phpoki.org/
Our group, Educational Technology at Middlebury College, are maintaining PHP bindings to the OSIDs. These bindings are PHP classes whose methods are unimplemented (each is just a "die()" statement), that are functionally equivalent to the Java OSID interfaces. To build PHP systems based around the OSIDs one could implement a service (such as Authentication) whose functionality is accessed via the classes and methods in the OSIDs. Concurrently/alternatively, one could write a client application that accesses a service via the classes and methods of the OSIDs and plug in any number of implementations of those services without re-writing how the client application calls the authentication system.
Harmoni Application Framework
http://harmoni.sf.net
This is project of our group, Educational Technology at Middlebury College, to develop a PHP application framework based around the OSIDs for use in the second generation of our educational tools, specifically our Segue Collaborative Learning System (http://segue.sf.net). The Harmoni Application Framework contains our implementations of many of the OSIDs as well as a plethora of other tools and functionality to ease rapid application development in PHP.
Sakai
http://www.sakaiproject.org/
(from the website above) "The Sakai Project is a community source software development effort to design, build and deploy a new Collaboration and Learning Environment (CLE) for higher education."
The Sakai Project includes the "Sakai application framework" and associated CMS tools, all in Java. I'm not sure of their current project status, but they will eventually be providing access to the various back-end services (such as Authentication, Authorization, and Repository) via implementations of the OSIDs.
Now that all of that is out of the way, on to how the O.K.I. OSIDs (and in particular the PHP version of them) may be able to help your efforts. I will assume that your client applications (Moodle and/or others) can call the necessary methods in the AuthN OSID to initiate the authentication sequence, something along the lines of the following pseudo-code:
(in a config somewhere, instantiate the appropriate AuthenticationManager object and an appropriate AuthenticationType object that identifies the particular authentication implementation to use as the OSID allows for multiple implementations to be accessed through a single AuthenticationManager)
// To log-in
if (!$authenticationManager->isUserAuthenticated($authenticationType)) {
$authenticationManager->authenticateUser($authenticationType);
}
$userId =& $authenticationManager->getUserId($authenticationType);
...
// To log-out
$authenticationManager->destroyAuthentication();
Below are several possible avenues that could be pursued.
Assuming that the current version of Sakai provides access to its authentication system via the AuthN OSID:
--- In PHP4 there is a module that allows Java classes to be instantiated from within a PHP script and have methods called on them as if they were PHP objects. This would probably only require some configuration to allow the appropriate Java-PHP object to be passed into your PHP script.
--- Alternatively, a simple PHP implementation of the Authentication OSID could be written that translates from the PHP object/method calls to the calls on the external Java Authentication implementation. I have not done much in the way of cross-language communication, but I am told that it can be "relatively" easy to get software to communicate across languages provided that there are equivalent APIs methods in both languages that do not require significant hacking around differing logical paradigms. Using the OSIDs as the common API could facilitate this process.
If the authentication system of Sakai (or your other campus authentication system) is not available via the AuthN OSID in any language, you could write a PHP (or Java) implementation of the AuthN OSID that queries your various authentication systems and then access this implementation from your client applications as mentioned above.
This avenue is basically adding an abstraction layer (your OSID implementation) between your client application and the underlying authentication system[s]. Going this route may prevent the need to re-write client applications as your university changes authentication systems as only your OSID implementation would need to change. As well, this could allow you to more easily plug in 3rd-party authentication implementations (such as the Harmoni ones to authenticate against LDAP, Banner, or a custom database), were that a desire.
In sum, using the O.K.I. interfaces in PHP may help your cross-language integration in that it provides a structure of parallel authentication methods that reduce the cross-language difficulty to simply making API-to-API calls across the language barrier rather than trying to make cross-language calls throughout your application.
I hope that this helps to answer your questions. Please post again if any particular area requires clarification.
--
Adam Franco
Educational Technology
Library and Info. Services
Middlebury College
Middlebury, VT 05753