Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By javanaut on
To continue a thread that was apparently started during DrupalCon over a few beers, I would like to discuss redesigning the distributed authentication system that drupal uses. One of the proposals that I favor is this one:
http://alec.bohemiandrive.com/perm/2005/02/18/distributed-authentication
The drupal-devel thread that started this discussion:
http://lists.drupal.org/archives/drupal-devel/2005-03/msg00708.html
I'll start with why the current design doesn't work very well for me.
My primary problem with it is that you (the user) have to trust the site that you're logging into using your remote server as an identity authority. You must trust that it is not logging your cleartext password anywhere for malicious purposes. This is a psychological barrier to using this technique in a widespread way. Especially considering the whole purpose of this is that you can go to some random drupal site and enter your local (say drupal.org) username/password to register. If I'm just now registering on a site, then I probably don't know enough about the site to say whether I should trust it or not.
My second problem is that the server that your logging into is sending your password to drupal.org (or your auth server) unencrypted. What this means is that any machine on the network between this server and drupal.org could sniff your username and password on drupal.org. It would be fairly easy to step into the middle of the communication line and either take over or listen in on this interaction. If a particularly popular site were targeted, many identities could be compromised this way.
Of lesser significance, the user profile page requires email address for remotely authenticated users. I don't think that this should be the case. Also, prompting remotely authenticated users to change their password is both faulty and misleading. Since they are authenticated remotely, this password only serves to confuse users into thinking that their remote account will be updated with the revised password...when in fact, it is not used at all.
On to the proposal for a new distributed auth mechanism.
The basic idea presented in the article above is:
1. The user is asked to log in to the remote site.
2. The user indicates that he'll be logging in via the account at his home site.
3. The remote site redirects the user to his home site, with the remote site's url embedded in the request.
4. The home site either prompts the user for his login and password or recognizes the user via an existing session cookie.
5. The home site generates a single-use token and pushes it (POSTs it, probably), along with some information about the user, to the remote site.
6. The home site redirects the user back to the remote site, embedding the token in the request.
7. The remote site recognizes the token and associates the user with his account information from the home site (starts a session, etc.)
An alternative based on ShareID:
1. The user is asked to log in to the remote site.
2. The user indicates that he'll be logging in via the account at his home site.
3. The remote site redirects the user to his home site, with the remote site's url embedded in the request.
4. The home site either prompts the user for his login and password or recognizes the user via an existing session cookie.
5. The home site redirects the user back to the remote site, embedding a single-use string token in the request.
6. The remote site receives the token from the user request and "redeems" it by embedding it anew in a request to the home site for information about the user.
7. The home site recognizes the token, cancels it (it's single-use), and responds to the remote site with information about the user.
8. The remote site uses the provided information to authenticate (or create a local account for) the user.
I didn't think that the two versions differed much in terms of security level. this post by Vlado offers a more simplified version.
One of the suggestions was that all of this transaction be handled via SSL. I don't see this as being practical for drupal's diversity of deployment environments. Very few personal websites would purchase an SSL certificate just to use drupal's distributed authentication. Additionally, most supported PHP installations have some form of encryption, so why not use it if it will work. Admittedly, the main encryption scheme that I would prefer for this would be public-key encryption, which I don't know of a native PHP interface for. Any ideas?
Another issue to tackle has to do with the ability to restrict which sites can be used for authentication. Maybe you are running a campus full of servers with a separate authentication (home) server for each department. Each of these may have varying capabilities. Some may have SSL certs installed on them, others may only be accessible via secure local networks. I would like this architecture to accommodate multiple security schemes (I can think of SSL, GPG, PGP, 3DES, plain text, etc). A given server would have a default security scheme as well as a list of optional schemes that it will support. Additionally, a separate configuration for each remote authentication server could have it's security scheme specified manually if that server offers more than one scheme. It was suggested that we attempt a secure connection type, then fall back to a less secure mode if that fails.
Some links were provied as an alternative to using SSL by way of PHPLib:
client side: crlogin.ihtml: http://tinyurl.com/6ysow
server side: local.inc, Example_Challenge_Auth(): http://tinyurl.com/3wvyo
I haven't read up on these yet, but I plan to.
Still another issue is how the user identifies their authentication server. Currently, it's in the format username@authserver, but this assumes that your site resides at the top level of your domain. What about username@authserver/drupal_install_dir/ scenarios? Would a user login as username@authserver/drupal_install_dir? Is this common enough to bother considering? What about odd port numbers?
User Profile data could be queried from the home server when a user is remotely authenticated. What, how and when it makes sense to do this is still not clear to me.
The authentication home site could offer services for tracking content posted at remote sites. There would have to be some means of allowing the remote server send back content on behalf of the user as well as some means of managing a session between the two servers (not just with the user's browser). RDF was suggested as a formatting option.
I'm sure I'm forgetting many of the ideas thrown around, so please feel free to add to this, clarify what you can and correct any inaccuracies that I've presented. The point of this post is to clarify the goals of Drupal's distributed authentication system and any ideas are welcomed.
Comments
Encryption and Javascript
I don't see how we can implement any form of encryption without Javascript support on the client side (not considering SSL). Of course, this can be an acceptable compromise, but we should be aware of this. But then, we'd need to implement everything: key agreement, cyphering, etc.
Still, it would seem to me that as long as the home site has SSL, then the log-in is secure, as long as the authentication token for the remote site is really single-use and tied to a single person (so interception is useless).
We can probably get a certificate for Drupal.org, this would mean that there is at least one trusted 'home' site for people to use.
--
If you have a problem, please search before posting a question.
I've been thinking about
I've been thinking about this for a while, and I don't see the dependency on Javascript here. Does JS perform encryption any better than PHP would?
Nevermind..
I just realized that you were talking about browser-to-server encrypted communication, not server-to-server communication. I think that if a site is secure enough to need encryption on that level that they'll use SSL for it. Rewriting all form submissions to use JS encryption would be a huge task, if even possible. It would be nice to accommodate non-SSL encryption, but I don't think it would be worth the effort considering how hit-or-miss javascript support is.
baby steps
nice thread ...
the first step is by far the most important one - implement the redirects such that you don't have to give your password to the remote site. eevrything else is nice to have.
IMO, we don't have to worry about SSL right now.
As far as transferring profile data, we currently do that in foaf.module using hook_user('login'). I think thats a very drupalish way. perhaps the biggest todo is to publicize this feature more. it is true that we may need to beef up security in this request (or merge it with the initial Auth request to home site).
I'm pretty sure that drupalAuth works today with sites in subdirs, and will continue to work under this scheme. The user is in control of where we redirect. We don't handle non standard port numbers today, but this would be an easy enhancement.
I like the format user@home_site. Matches both email and jabber.
Content tracking service is interesting but lets table that. It dilutes attention from more pressing concerns.
You can restrict login from only trusted sites today using our 'username validation' settings in Admin. If you wanted something else, it would be easy to implement using hook_user('validate')
Re: baby steps
I agree that this should be approached a little at a time. I just wanted to lay all of the issues out on the table so that we could pick and choose what to do first. I agree that the redirect scheme would cover my two greatest concerns with the current system. I even think that doing this over insecure channels would be far more secure than the current implementation. The only potential problem that I can see with a piecemeal implementation schedule is version compatibility. If we could design in some means to accommodate future changes, that might keep version compatibility between sites from becoming an issue. It would suck to have your auth server upgrade and lock you out of your favorite site. Maybe number the protocol versions?
I forgot to mention FOAF (I meant to). Yes, this handles a lot of the profile data transfer issues.
I never tested drupal's capability to have user@host/subdir/foo type of usernames, so I'll take your word on that. I was more referencing the article's formatting suggestion. I also like the user@host format and wouldn't want to break that.
Re: content tracking...agreed. It's definitely a "nice-to-have" but this challenge is already big enough without adding that. Besides, I think that would be more likely the domain of a contrib module than a core feature, but that's just my opinion.
If you're going to postpone the multiple security schemes option for now, than per-site trust/configuration won't need to change much from the current system.
Design Flexibility
One of my interests for this protocol has to do with server-to-server communications beyond the point of authentication. Additionally, the initial authentication should offer some sort of data interface that modules could hook into. I don't think that this is outside the scope of an initial distributed auth effort. I also reallize that with distributed applications, future changes mean version management/conflict, so the more we can plan at this phase, the better. My suggestions:
I would like to include XMLRPC services that could be shared between servers. These could be configured on a per-session basis. This functionality would not need to exist at the time the distributed auth mechanism is created, but the auth framework should accommodate it.
Referring to the first auth process (using POST method), step 3 would be altered to append a list of named services (comma separated) that it offers to the homesite as well as an optional list of services that it requests of the homesite. There's currently no need to go into the details of these services other than to say that each service will have a unique name and be used to call upon an XMLRPC interface. If none are specified, then it is assumed that no services are offered.
When the homesite POSTs back content to the remote site, it will include the local (homesite) username, a server-to-server session cookie (with expiration date/time as well as server's current time), and a "data" packet containing arbitrary (to be defined later) XML data that is supplied by module hooks. This POST will be done using the XMLRPC interface.
The remote site then responds to the POST with acknowledgement of request validity (1 or 0) and a "data" packet sent in response to the one POSTed and similarly formatted.
After the initial authentication, XMLRPC calls can be made in either direction using the session cookie. Both homesite and remote site should accept this cookie until it expires or the user logs out of one of the servers (or should this apply only to logging out of the remote server? I might want to authenticate against my homesite, then logout of it).
This is a start on the actual protocol formatting discussion, so please feel free to contribute to it. After looking at how Sxip and Typekey work, I'm not convinced that they will suffice for drupal (for various reasons). Sharing services between hosts is a huge opportunity for development, IMO, and I am interested in pushing this forward. Attaching service authorization to a Sxip/Typekey style "redirect" authentication would be optimal.
server
I wonder is there another similat peer to peer CMS, per example I have modified my http://www.localareaflorist.com/ with the method you meantion above.
A purely user-interface level
I myself had wondered about the security implications of the livejournal module, for example, which I have enabled on my site--but would probably not be inclined to trust on someone else's site.
On a purely user-interface level, I can't for the life of me figure out how to explain livejournal auth in a manner that the casual web surfer can understand. username@livejournal.com seems pretty intuitive to me, but from looking at my logs, I have yet to see someone successfully do this on the first try. =) I wonder if I might have more success making a login block with a radio selector (local account, drupal.org, livejournal.com) or somesuch.
-----------------
Govorite po-russkij? Want to?
http://www.sobrania.net/russian
Re: LJ
I just paraphrased this authentication scheme to the lj_dev community. There's only one comment and it was negatively received.
I, too, take issue with matters of trust. I'm seeking a way around it. I can't come up with instructions that are any better than "c'mon guys, just trust me".
I think the user@host format isn't too difficult to explain, so you may want to have a faq on how remote authentication works on your site.
Good feedback from lj_dev
I have some reading to do this weekend it seems:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
http://shibboleth.internet2.edu/
http://www.projectliberty.org/resources/specifications.php
http://www.typekey.com/
BTW, Livejournal will soon be implementing Sxip client and server as well as typekey client from what I read. They'll act as a typekey server, too once that is supported. Good news for the livejournal auth module.
summaries
i tried to read up on those links but they seemed infinitely more complex than our current Distributed Auth. If someone could summarize the key points in bullet form, that would be swell.
Sorry about posting before reading..
In order,
SAML appears to do with federated identities and the exchange of profile data. Admittedly, I haven't read the entirety of the documentation provided here, but it already seems way overkill for where we're going at this point.
Shibboleth is an authorization mechanism (as opposed to an authentication mechanism). This may be handy (more as a referenceonce than a design doc or solution) when/if we go beyond simple authentication into sharing services in a restricted way. It sits on top of SAML (and a slew of other FLAs). an overview.
Liberty Alliance seems to have a useful design. From their developer guide:
Identity
Simplified Sign-On
Single Logout
Network Identity / Federated Identity
Circle of Trust
–Principal
–Identity Provider (IdP)
–Service Provider (SP)
–Liberty Enabled Clients or Proxies (LECP)
Pseudonyms & Anonymity
Authentication Assertion (SAML)
This seems to be a hearty/secure approach. Again, it's overkill for where I think drupal is going any time soon. Their site markets to corporations, but they claim Apache projects supports some of their efforts.
Typekey seems like it's more in line with our next steps here. In fact, a developer on lj_dev said that my description of the login process was identical to the one that Typekey uses. Typekey is a service that is still in alpha testing. They will soon offer developer guides for writing clients, and I assume that it would be easy enough to figure out what the server is doing and modify it to drupal's needs. It may benefit us to use an existing protocol, even if its not completely open. I never saw anything on their site about licensing, but the service is not live yet. Something to watch, definitely.
I didn't mention Sxip here, but they would fall into the category of "delegated" authentication servers. I don't really know much about their design, but it seems more like a service provider arrangement than a means of distributed authenticationon.
SXIP
The (new) SXIP module is highly secure. We could re-use some of the concepts to base Drupal's dist-auth on. The description you have of home sites is virtually identical to the way SXIP works today.
I'll get Andy Smith, their main developer, to come in and comment and leave pointers to appropriate information. Walkah is also well versed in this.
I just read through the sxip
I just read through the sxip drupal module, and it seems fairly straightforward, though I'm sure there are sxip details that aren't implemented by this module.
My only concern would be the practicality of implementing a Sxip Homesite. The only implementation that I saw was J2EE (and 12M compressed!). I haven't looked at the code yet, but would a Sxip Homesite implementation be too big for our purposes here?
Turnkey Homesites
It is likely that Bryght will be running a homesite for any of its users. We may additionally run a homesite for Drupal.org/the Drupal community if there is interest.
Further down the line I believe there are plans from Sxip to be able to run "turn key" homesites that don't require Java and that most systems capable of running Drupal could also run.
In any case, I think Drupal's dist auth could still use an upgrade, as well as some UI tweaks. I think these could be the basis for more pluggable auth schemes.
at last
I have tried to do the same on my http://smsaudio.co.uk, and it was successfull. Thank you, guy.
Freelance Web Designer
http://www.pdesigner.net
Auth fails
I have some problem with authontication, some time I can not enter with dufferent user names and passwords, seems it is temrorary bug,
How that can be fixed?
I meant my this website 3Ds Max Tutorials
http://www.3dmax-tutorials.com
This is a nice step forward.
This is a nice step forward. I would be glad to help where possible. These are my imaginings on how authentication would occur:
1) User logins in to remote site as user@drupal.org
2) Remote site redirects user to http://drupal.org/user/remote/?redirect=http://remote.site/user/login/re...
3) user authenticates at drupal.org; drupal.org redirects user back to remote site with a ticketid appended to the url
4) remote site parses ticket id and attempts to contact drupal.org to see if ticketid is valid; this can be done via a simple GET request, SOAP request, XML-RPC request, etc
5) drupal.org responds with yes or no, and possibly information about the user that drupal.org is willing to give up
6) remote site parses returned info, creates session, and redirects user to previously browsed page
SSL would be nice, but even without it, we are still improving security in one major way: a user's cleartext password can never be stored by the remote site. A number of encryption schemes would be nice. If you wanted to explicitly trust a few sites you could create GPG keys and store them.
That's how I see it
Humor my imagination for a moment, if you will, and ponder future paths for this:
Reading up this morning about service providers and authorization services, I'm inclined to think about shared services between servers. Ponder this example:
1) User logins in to remote site as user@drupal.org
2) Remote site redirects user to http://drupal.org/user/remote/?services_requested=post,edit,profiledata&.......
3) user authenticates at drupal.org; drupal.org confirms that the user grants the remote site access to post, edit, and profiledata at drupal.org.
4) user acknowledges and accepts the request. drupal.org redirects user back to remote site with a ticketid appended to the url
4) remote site parses ticket id and attempts to contact drupal.org to see if ticketid is valid (redeems the ticket); this can be done via a simple GET request, SOAP request, XML-RPC request, etc
5) drupal.org responds with yes or no, and gets a server-to-server session cookie for user-delegated actions, possibly information about the user that drupal.org is willing to give up
6) remote site parses returned info, creates session, and redirects user to previously browsed page
7) remote site performs actions on drupal.org on behalf of the user (posting content, altering content, etc).
8) user visits drupal.org and manages remote sessions (deletes, restricts/extends authorization for).
This would allow a home server to expose services to the remote server. I could see a whole new api built around server-to-server messaging. Even something as simple as a logging service that documented everything a user posts on other servers with contextual links and such would be damn handy.
[/futuremode]
I think at this point that getting this simple, functional and secure will be top priority. I still haven't done much research on the availability of encryption schemes on popular LAMP hosts. Does anybody else know about this?
indeed
i have to agree that a home site that catalogged everywhere that I've left a comment would be damn useful.
As I see it, the only major
As I see it, the only major thing that core would need to do to support this would be managing a server-to-server session cookie (or other mechanism) as well as a simple API for talking back and forth with each other (xmlrpc perhaps). Defining and implementing the actual services could be handled via contrib modules.
Encryption
It would be quite easy to extend this authentication with encryption, by having an optional passord set for each site you want to allow authentication from and to.
The only thing we must make sure the admin understands is that if he wants to enable encryption for drupal.org, drupal.org must also set up encryption for requests coming from him.
If no password is set, the request is sent i clear text, if a password is set (and maybe even one of several encryption schemes are chosen) the authentication is encrypted.
Another advantage by using encryption is that it also provides an authentication of the remote site.
With everything en clear text, a number of "man in the middle" attacks are possible as I can simply spoof both the one time token, and the "yes" or "no" on whether to accept the user or not.
From an ease of
From an ease of implementation point of view, I would prefer to do this from a separate module. The "payload" could be encoded while the connection is not. I think, in general, that if two sites were requiring real encryption, they would both have SSL certificates. It would make sense to have a module hook that encrypts the payload being sent back to the remote site, but only if the remote site has stated what it's capable of decrypting. I could see it unfolding like this:
1. User requests remote auth on homesite using auth protocol "drupal".
2. Remote site calls module_invoke_all('auth_prepare_send_url') to get a list of query arguments to send in the initial redirect. This could include the server's URL, a list of all available services on remote, a list of all requested services on homesite and a generated encoding key to be used to unlock return messages.
3. Remote site uses URL to redirect user to homesite login page.
4. Homesite receives browser's request and validates user's credentials.
5. Homesite prepares an XMLRPC response for the remote site by parsing all of the initial query args and passing them to modules via some hook('auth_validate_args', $args_array). This hook would return XML responses to be placed in the POSTed payload.
6. Homesite would add to the payload responses the 'requested services' parameter with a yes or no indicating whether the service is supported/allowed. Homesite also adds a session ID to the payload and a one-time use login token that the user would 'spend' upon returning to the remote site.
7. Homesite calls $new_payload = module_invoke_all('auth_prepare_post', $payload); which is where the encryption module would use the initial request's key to encrypt the package.
8. Homesite prepares the XMLRPC POST with the $new_payload value and sends it to remote server.
9. Remote server receives POST and uses key to decrypt the payload.
10. Remote server callls module_invoke_all('auth_received_response'), $payload); to generate any additional handshake data that is sent in response to the POST.
11. Homesite takes response to POST and calls module_invoke_all('auth_handshake', $response);
12. Homesite redirects user to remote site with token attached to URL.
13. Remote site validates token and continues to let the user in (register/login).
I seem to get some sick thrill out of rewriting a step-by-step process several times with slight differences between each. Hopefully, I have kept the distinctions clear between what I would expect the core module to do and what I would expect a contrib module to do. I don't think that the core should have any encryption in it, but instead perform all key exchange/encryption using separate modules. This would keep core nice and pretty while keeping implemention details of encryption algorithms separated. The only changes to core to support this would be a 'auth_prepare_send_url', 'auth_prepare_post', 'auth_received_response' and 'auth_handshake' hook. Is this sufficient flexibility to do proper encryption from a module?
The only encryption-related feature not mentioned here would be the "try https before http" idea. I think this would be good, but there may be some sites where the server running on https is not the same as the one on http, so this would have to be accommodated.
I've started on an module..
Not much by way of actual code yet, but I have the first round of high-level pseudocode laid out in sequence for the authentication process:
RS = Remote Site (the one you want access to)
HS = Home Site (the one you enter your username/password at)
From RS, this module performs the following:
Handle hook_auth functionality
parse HS $server info from user login form ("@example.com")
call $qargs = module_invoke_all('auth_prepare_send_url') to get an array of query arguments
* this module should implmement hook_auth_prepare_send_url() to append
* * specify XMLRPC POST URL (probably $base_url'/xmlrpc.php')
* * generate RStoken (and save in DB with expiration timestamp)
* redirect Browser to HS $server/auth/rlogin?format_qargs($qargs).
From the Home site (HS), this module performs the following:
HS receives the browser's request and logs query args ($qargs) passed in keyed on RStoken/RS
HS prompts the user to login, explaining that RS is attempting to access their authentication
User logs in with username/password/checkbox acknowledging the remote site
HS validates user's login credentials
HS verifies that User's remote auth request was accepted (checkbox checked)
HS calls $payload = module_invoke_all('auth_handle_args', $qargs); ($payload is an XML string)
HS calls $new_payload = module_invoke_all('auth_pack_payload', $payload);
HS generates and saves HSsession keyed by $remote_site_url
HS generates HSToken
HS creates XMLRPC POST including HSsession, HSToken, md5(RStoken) and $new_payload
From Backplane POST from HS, RS performs the following:
RS parses out HSsession, HSToken, RStoken and $new_payload from XMLRPC POST.
RS identifies user using md5(RSToken) and verifies that it is valid.
RS saves HSToken and HSsession
RS unpacks $new_payload data by calling $payload = module_invoke_all('auth_unpack_payload', $new_payload);
RS processes POSTed data and generates handshake by calling $response = module_invoke_all('auth_handle_response'), $payload);
RS responds to XMLRPC POST by creating a message using $response and the destination to send the user to (RSdest)
From Backplane POST response from RS, HS performs the following:
HS calls $resp_args = module_invoke_all('auth_handshake', $response);
HS includes md5(HStoken) and RSToken in the $resp_args
HS constructs url pointing to $RSdest?$resp_args
HS redirects User back to RS
From RS after being authenticated on HS, RS performs the following:
RS parses query args looking for HStoken
RS looks up md5(HStoken) and validates the user.
RS associates the user (once local acct is created/logged in) with the HSsession
Notice that I've taken out any mention of services offered by one or the other server. I think this design will be flexible enough to accommodate a separate remote services module. As well, encryption modules will have the opportunity to "pack" and "unpack" the data. There will be a 2-key, 2-channel, 1-way encrypted exchange (using the well supported md5() function), so only very clever man-in-2-middles attacks will ever compromise the exchange.
Iif anyone would care to critique this approach, I would appreciate it. I won't have time to actually code this for another week or so (unless I steal some more time). If anybody's interested and/or ambitious, feel free.
FYI
There's another wheel out there, but it's much closer to my own vision of a truly distributed auth system than existing wheels:
http://www.danga.com/yadis/
These are the guys that run livejournal.
cool design
i like this one a lot as well. very nice one page description of how it works. it is slightly more complex than the other scheme we discussed, but with some advantages. i could go either way ...
One benefit to this is a
One benefit to this is a political one. Danga is officially related to Six Apart. Though this design would compete with their TypeKey service, I'm sure it would spread quickly nonetheless. Such a technology would work best if it were pervasive and cross-platform/cross-cms, so having support from one of the bigger players in the market would be nice.
The only usability issue that I see is with using FOAF for identifying the authentication server and account. How many users know what their FOAF url is? It's currently not clear to me how you would allow specific services to interact between servers (e.g. log all comments/posts/replies, etc). I suppose that once you were done with the initial authentication handshake, additional processes could follow for supporting more advanced services (but degrade elegantly if they're not supported).
I know I'm not going to have time for any new development for another few weeks still, but I will be following the development of Yadis.
Some brief thoughts (from a non-programmer)
logging of remote activities by home.site:
home.site has remote_cron which scans sites listed in home.site/user/myuser/remote/remote1.site remote2.site etc.
(nodes which have previously been created by the user before logging into the remote site, or in the process of the first succesful handshake)
searches remote1.site for new content created by myuser@home.site, copies to appropriate remote activity node, a blog for example: home.site/user/myuser/remote/remote1.site/blogs/
and so on for remote2.site etc...
this led me to think about site level interlinking between trusting admins:
home.site/remote/remote.site/node/123
(a remote node displayed within the theme, and with the menus of home.site)
The idea is basically dynamic syndication, so if within the remote node, you click on a link for another page (remote.site/node/123) it opens it within the home theme/environment. Admins could have the option of putting a disclaimer or custom heading at the top of all remote nodes, or could limit the syndication by taxonomy or module (remote stores would be a challenge), or role (anonymous users can't see some or all of the remote site material), or any of the other methods of access control. Any click which failed the home.site trust policy would send the user to view the node directly at remote.site. On the other end, remote.site can limit what content can be syndicated inline by home.site as well, with the same result for a failed test.
The easiest way to do that last part would be for the home.site to have a user account on remote.site for the purpose of inline syndication, which can then be assigned roles (which could be more limiting than anonymous, if that's what the admin wants).
I had some thoughts on FOAF, buddylists and making friends across sites... but this post is too long already. I hope I'm being helpful.
FYI - 2
Yadis has changed names into OpenId. There's a slashdot story about it today.
Restricting which sites can be used for authentication.
Restricting which sites can be used for authentication would be really useful.
This is one of the first features that need to be added to the authentication scheme.
The list of allowed websites should be shown everytime a user has to register or lost a password.
It's also a great way of exchanging links and members with friends.
Marcel
Wholesale directory and trade leads
Business directory for importers and exporters
alreay possible
you can create access rules for an email address. that *might* help address your need. as you say, this could be improved a lot.
SAML?
I see that SAML and some of the other federation standards have been mentioned. That is totally the way to go as it would interoperate with anyone who chooses to implement the SAML standard. No point re-inventing the wheel. Someone mentioned that SAML seemed to complicated, but it really isn't. In fact most of the federation standards are very similar to the concepts discussed here.
John
Emu Remote Authentication against Drupal (4.6/ 4.7) v0.9
I am in the process of hacking Mediawiki and Scuttle to authenticate against a Drupal site's user list. ALong the way I have created GPL Emu Remote Authentication against Drupal (4.6/ 4.7)
Emu creates an encrypted webservice that runs on the drupal server, serving authentication requests to requesters who know a secret ticket number set by the drupal site owner.
Integration into off site php applications is via a simple to use php function called
drupal_user_validate(user,pass)Your comments are welcome.