--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To post to this group, send email to simple...@googlegroups.com.
To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en.
On 6/01/11 10:39 AM, Son Tran wrote:
> As far as I known, it's still 1.0 but with some of modification :)
>
The /current/ Facebook Auth uses an old facebook library to provide
OAuth support. The user information is returned by their deprecated REST
api:
http://developers.facebook.com/docs/reference/rest/users.getInfo
The Windows Live ID auth module (not included in 1.7 or HEAD at the
moment) http://www.terena.org/~schofield/simpleSAMLphp/ uses OAuth-WRAP
to authenticate (the precursor to OAuth 2.0).
OAuth-WRAP is seriously simple in comparison with OAuth 1.0 as it
transports over HTTPS and removes the need to sign requests. While there
is much more in OAuth 2.0 if you only need to redirect a user for
authentication purposes and retrieve an accessToken for a query of their
profile - easy.
If you want to perform further queries of their profile, activities,
social graph etc then simpleSAMLphp needs a way to convey this back to
your application so it can continue querying information about you.
Adding all this functionality to simpleSAMLphp wouldn't be useful (in my
opinion).
My 4th question in "A party of social networking authsources" (Dec 30th
10:04pm CET) asked:
Q4: These OAuth/OAuth WRAP authsources internally have access
to an accessToken combination + expiry that could be used to
update/continue to query the API/social graphs of their
respective end systems. Would it be useful to your applications
to return these via attributes?
You wouldn't need to return your application key or secret via
attributes (you can exchange them with your application easily) - but if
you return the accessToken for the user to your application the problem
is /almost/ solved.
If you test the Windows Live ID authsource:
https://tasman.terena.org/openid-bridge/module.php/core/authenticate.php?as=windowslive
It returns various REST endpoints to query for more info - such as:
https://activities.apis.live.net/V4.1/cid-USERIDGOESHERE/MyActivities
https://psm.apis.live.net/V4.1/cid-USERIDGOESHERE/StatusMessage
https://contacts.apis.live.net/V4.1/cid-USERIDGOESHERE/Contacts/AllContacts
So how should the OAuth/OAuth-WRAP/OAuth2 accessToken (and secret for
OAuth1.0) be returned?
This equally applies to LinkedIn, MySpace, Twitter, Google (and a range
of OAuth X social websites).
-Brook
--
===========================================
Brook Schofield, TERENA Project Development Officer
TERENA Secretariat, Singel 468 D, 1017 AW Amsterdam, The Netherlands
Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991
www.terena.org
OAuth-WRAP is seriously simple in comparison with OAuth 1.0 as it
transports over HTTPS and removes the need to sign requests. While there
is much more in OAuth 2.0 if you only need to redirect a user for
authentication purposes and retrieve an accessToken for a query of their
profile - easy.
From the above can I assume you'll be updating the authfacebook module?
From the above can I assume you'll be updating the authfacebook module?> That would be all, the rest really is application specific I'd say.
> Anyway, I hope this will make it in 1.7.x or so....
I'd suggest you have a look at our OAuth2 project (http://www.rediris.es/oauth2
)
Be goode,
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Red.es - RedIRIS
The Spanish NREN
e-mail: diego...@rediris.es
jid: diego...@rediris.es
Tel: +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------
--
Maybe you remember that in the latest RedIRIS conference we spoke about
the OAuth2 filter module we did for SSp, built on that OAuth2 library,
as alternate authz proof of concept with the groups manager.
The filter simply acts as an OAuth2lib client, getting the pertinent
information from the OAuth2 Resource Server (through the groups manager
API) and adding it to the user attributes.
It runs fine, but, naturally, even if the groups administrator makes
some change to the user status, those attributes stay unchanged until
the user logout and next login, so to have a more restful-like behaviour
we opted for moving the OAuth2 client to the application itself, as
finally showed in the demo.
Regards,
JA.
--
Jos� Alfonso Accino
Systems and Network Management
Central IT Services
University of M�laga (Spain)