OAuth is simply ensuring that both parties, requester and responder has the same reference to a user, ‘the current user’, and they both independently may authenticate the user (out of scope of oauth). What is the added value of OAuth here is that it allows you to do backchannel requests regarding a specifc user, ‘the current user’, without using a privacy-invasive identifier. And as a happy coincidence, the OAuth protocol is so simple, it can be implemented in a snap.

Trust model is partly out of scope of the OAuth protocol. Although it has some very useful hooks that allows you to do what you want.

First, it has provider key/secrets, which is a way of managing ‘registered’ consumers, that are allowed to communicate and talk to the oauth provider. You can imagine several ways of handling this:

1. Self-registration of consumers (most common).
2. Self-registration, but with ack from the provider administrator.
3. Provider administrator configures the trusted consumers

When you have a list of consumers, you may setup access control per consumer. In this scenario you could also let the VO admin configure which consumer that are allowed to access what data.

In addition, OAuth gives you the ability to add user consent to release of VO information, and you can also give the user options about what data the consumer may retrieve in that particular session. Including user consent is not straight forward using SAML 2.0 AttributesQueries (backchannel).

To summarize, we may define an apprioriate trust model about registration of consumers and release of VO information - and then OAuth will much likely fit with that model.

• Read more about OAuth on my blog

I created Secure Mail a couple of weeks ago, to be able to verify the sender of some kind of important messages related to Feide. This works great for sending public keys, certificates, metadata updates etc.

But today I had to send a message containing a secret URL, so I also had to ensure confidentialiy. I added a checkbox when you send message, that limits access to the message to only receivers that are able to authenticate with Feide and having a registered mail-address that match the intended receiver of the message.

Here is a screenshot:

I've now finally completed the drupal simpleSAMLphp authentication module.

• Project homepage and downoad

I appreciate if people test it, and report issues to me.The module implements Single Sign-On and Single Log-Out, and also have functionality for automatic role population from SAML attributes.I have setup this module on this blog right now. So if you want to test it, then click "federated login" and login with either Feide Test Environment or with Open IdP (guest users). When you have logged in, you may add a comment on this blog entry! Thanks!

Sun's Sun Access Manager Policy Agent for Apache is limited sucks because it is "impossible" to deploy on any other Linux than Red Hat Enterprise.

Having an apache module that works with Feide is important for us, so we are looking on alternatives. One idea is to use saml2php (OpenSSO PHP Extension) together with Auth MemCookie. Olav Morken helped us to setup a proof of concept demo site, and write a detailed document on how to setup saml2php with Auth MemCookie.

• Read the document describing how to setup saml2php with AuhMemCookie, enabling authorization in apache with a SAML 2.0 federation

The document is checked-in to saml2php CVS repository, so you will also get this document when you download saml2php.

A new sessionhandler is also added to saml2php CVS, named authmemcookie, found under: openssophp/spi/sessionhandling/authmemcookie.php.