Elgg currently provide various means of authentication which is sufficient for most current needs. However, to help further distinguish Elgg, a feature that will allow ALL Elgg public facing sites to be networked, with permission from the admins but only for specific/approved sites will place Elgg up a notch as I don't think there is anything out there that does that.
Think of this much like an Elgg site as a member. A site can then "friend" another site (one-way trust relationship) and the friend site admin will get a notification which they can either ignore or reciprocate. The river can then flow within these sites, either one way or both ways with the option to allow users to access the friend site from their home site seamlessly.
Thoughts?
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
Some of my notes from my initial testing. It has been some months.. I guess I got tied up with other everything else... Anyway - this has been mostly a "hobby" sort of development because I lost my former School Project partner.. b-u-t now it looks like I am starting gain new buddies for "deferated" sites. If anyone reading this is interested and can handle PHP, XMLRPC, Web Services and wants to be involved with what we're aiming to develop, just message either one of us and we'll talk.
The code does say "School..." but once you drop tha word and we simply reference "ElggSite" -- nothing else in the code changes. I just happened to say "School' because that was my focus when I started this..
NB: These snippets are from actual working codem which I put on 3 different servers to see how they would talk to each other + also sent a packet to
,"sid" => "community.elgg.org"
,"loc" => "/elgg/xml-rpc.php"
just to how that server would respond ;-) to
"hello.world" => array ("hello", "world" )
,"pingback.ping" =>
array
( . . .
ALEX:
Note the "site signature" in the protocol ? That is what I referred to to as "generated using OpenSSL's supplied functions". This plus the session token handshaking should keep the comms pretty clean..
<?php
/* web_service_api.php */
$xmlrpc_methods = array();
$xmlrpc_methods['request.federation']="request_federation";
$xmlrpc_methods['receive.publickey']="receive_publickey";
$xmlrpc_methods['say.Hello'] = "say_Hello";
$xmlrpc_methods['import.user'] = "import_User";
$xmlrpc_methods['news.getNewsList'] = "news_getNewsList";
$xmlrpc_methods['news.viewNewsItem'] = "news_viewNewsItem";
$xmlrpc_methods['method_not_found'] = "XMLRPC_method_not_found";
?>
<?php
/* client.php */
/**`````````````````````````````````````````````````````````````````````````````````
*/
$DBG=TRUE;
$DBG=FALSE;
/**`````````````````````````````````````````````````````````````````````````````````
xml-rpc library
*/
include ( "CONNECT_MY_SCHOOL_WS_KD_XMLRPC.php" );
/**`````````````````````````````````````````````````````````````````````````````````
*/
$SERVER =
array
(
array
(
"EXE" => 1
,"sid" => "localhost"
,"loc" => "/elgg15RELPKGS/XMLRPCserver/CONNECT_MY_SCHOOL_WS_SERVER.php"
,"methods" =>
array
(
"say.Hello" => "Y"
, "receive.publickey" =>
array
(
"www.SchoolName.XXX" // 0 = site name char (128) (http://www.) SchoolName.XXX
,"123" // 1 = site guid bigint(20)
,"A1B2C3D4E5F6G708A1B2C3D4E5F6G708" // 2 = public key char (64)
)
,
"request.federation" =>
array
(
"www.SchoolName.XXX" // 0 = site name char (128) (http://www.) SchoolName.XXX
,"123" // 1 = site guid bigint(20)
,"A1B2C3D4E5F6G708A1B2C3D4E5F6G708" // 2 = site signature char (64)
,"A1B2C3D4E5F6G708" // 5 = admin phash char(32)
,"admin@www.SchoolName.XXX" // 6 = email text
,"EN" // 7 = language varchar(6)
,"" // 8 = ... unused
,"" // 9 = ... unused
)
)
)
,
array
(
"EXE" => -1
,"sid" => "www.myteamfaces.com"
,"loc" => "/elgg/xml-rpc.php"
,"methods" =>
array
(
"say.Hello" => "Y"
)
)
,
array
(
"EXE" => -1
,"sid" => "elgg15.ensci.us"
,"loc" => "/elgg/xml-rpc.php"
,"methods" =>
array
(
"say.Hello" => "Y"
)
)
,
array
(
"EXE" => 1
,"sid" => "localhost"
,"loc" => "/elgg15RELPKGS/xml-rpc.php"
,"methods" =>
array
(
"hello.world" => array ("hello", "world" )
,"pingback.ping" =>
array
(
"www.ensci.us/elgg15/"
,"www.xxxxxpages.com/elgg/"
)
)
)
,
array
(
"EXE" => -1
,"sid" => "community.elgg.org"
,"loc" => "/elgg/xml-rpc.php"
,"methods" =>
array
(
"say.Hello" => "Y"
)
)
)
;
?>
@alex, my initial fear is ebbing. Don't get me wrong I can see great benefits to it. Yes I hope my content will draw people to my site, yet to be seen, or should I say yet developed.
@Dhrup, does the use of import user drag the entire user over profile or just certain info? If it is all can you set a cron job to run every night that will update the friend sites user profile? So if I add a picture to my album on site 1, will friend site be able to be auto updated via cron job?
Hmmm..
I've posted the code snippets hoping to generate more interest and discussions in this area ;-)
The "Import User" is not completed. There many different options for the functioning of spmething like "import user" ( or content ) in the context of "federating". There were some comments and discussions at BostonElggCamp2009 where different approaches to such a scenario was evident. Everybody has a slightly different meaning of, say "Import user".
For now Alex and I will work around the Academic scenario because - 1) That's where I started from and 2) His community in quite similar.
I hope we eventually end up with something that can is extensible and masssage-able.
We've started looking at this as well, and we'll be wanting to do this more in the future.
The OAuth plugin that I just released will help this effort, since it will allow secure delegated API access to a remote Elgg site. This means that we've got the endpoints (the API), and the protection (OAuth), now we just need good piping to run between them.
OAuth is not a good match for authentication and account creation - you really should be using OpenID for that. Twitter's use of OAuth as part of their "connect" piece is a bad match for the technology.
More to the point: once an account is created and authenticated (using something like OpenID), the user can *authorize* API access between two sites using OAuth.
@Dave the problem with turning it off is that your site does not appear as attractive as other sites. It's true the site will only be successful if it fullfils a need, I am just trying to input the user feeling (well one anyway). I don't want my site to become a dinosaur by not keeping up with trends but want to protect the user growth is all.
By the way Dave did you get a chance to look at me ellg mail I sent last week?
Justin:
As someone who has used OpenID to integrate multiple apps in the past, I have to disagree with your comments on OpenID. OpenID is deliberately intended as a lightweight single sign on solution. Federating websites is far more than that. Using OpenID to integrate apps is a big job and can be like forcing a square peg into a round hole.
I'm not sure that OAuth is the correct tool either. SAML is the main software designed for federating websites. Implementing SAML properly for Elgg would be a big job, but it is probably the best federation solution out there, especially if Elgg wants to play in the institutional arena, where SAML and its variant Shibboleth are the main players.
Kevin: I wasn't saying that OpenID was the whole solution -- far from it. It helps with the problem of accepting credentials from remote sites, and part of setting up accounts (with the SREG and AX extensions). It doesn't help with synchronization or data transport beyond login, but that initial login is a big step. OAuth helps with securing a federation API, but it is not in itself an API. This is precisely the piping that we need to connect different sites.
I don't think that SAML's really the best approach, since all of its trust framework is built off of administrator-level trust. It also doesn't really give us the federation APIs that we need, just a security framework that could wrap them.
Has anyone looked at Googlewave yet? Since we (elgg community) really haven't moved anything forward with regard to federation, if you haven't seen GoogleWave's proposed/planned federation protocol, it may help with future discussions/consideration for federating elggs as well as with googlewave.
http://www.waveprotocol.org
http://www.waveprotocol.org/wave-community-principles
I'm just getting started to reading/understanding this so I dont have much opinion on it at this point other than perhaps we go with the flow? Just wanted to share early so we can have an intelligent, informed and lively discussion.
Hello, I push up this interresting topic...
Why don't you use the same system that Status.net is using. Servers easilly exchange data and a logged user on server A can subscribe to friend on server B without creating an account on server B.
I find this system very usefull.
Why everybody uses Facebook ? because everybody uses Facebook. If different elgg servers could communicate, a user could create an account on his preferred (or own) one and then accessed to his friend information even if he use a different one. I think a notice in the river could be sufficent, inviting the reader to click and go to the second server to see the detail.
It seems to be a decentralized social network system and every elgg server would be more attractive.
- Previous
- 1
- 2
- 3
- Next
You must log in to post replies.