Hi All,
To add to Joost's list, (Joost types a lot faster ;), the other
"vandijk@surfnet" has some highlights on the application site of things
@ SURFnet
- We are currently rolling out a service for supporting group relations
over multiple IdP's and multiple SURFnet services, nicknamed
SURFgroupie. The service is based on Internet2's Grouper and will
feature a userfriendly self-service GUI for endusers, which will be
release as an open source product later this year. The group service
will be used as an attribute provider to supply group relation
attributes to applications @login.
Question: Would anyone be interested in trying to work with us to create
such a setup with a number of international IdP's in 2010 as a test? As
I do not want to access real interesting services (yet), I would like to
keep away from any legal federation stuff just now. First see and try
how this would work out technically.
- Using Michael Linden's memo on provisioning and deprovision as a
starting point, we've investigated what would be the scenarios for
provisioning and deprovising applications in identity federations, both
with a centralized and with a decentralized setup.
Interesting is that the overall challenges will be very alike, as well
as the possible solutions. Both types of federations seem to benefit
from a setup where a component is introduced to aid the IdP's and SP's
in this process.
More can be found at
http://www.surfnet.nl/Documents/indi-2009-07-019 (Provisioning and
deprovisioning in an_identity federation_final-1.2).pdf
- We've published our report on 'Collaboration Infrastructure',
proposing an architecture for supporting VO type like collaboration
based on federated access and group relations.
We also present the state of affairs regarding the support of open
standards within the collaboration field, based on functional
requirements defined by members of our institutions.
http://www.surfnet.nl/Documents/indi-2009-07-020%20(Report%20Collaboration%20Infrastructure).pdf- As a follow up on the above report we've started a project to try and
build a proof of concept of such an infrastucture.
To showcase the results we've also included an effort to setup an
OpenSocial based 'social network' portal to serve as a entrypoint for
the services. So far we have introduced or implemented federated
authentication, group relations and on-the-fly provisioning of users and
groups into:
* Alfresco - Document sharing (based on OIOSAML/OpenSAML 2.0)
* Adobe Connect - Building on previous work of both SURFnet and ARNES we
have created a federated version of Adobe connect, for which the
provisioning is handled on the fly using a generic authentication and
provisioning module written for Apache. This allows us to set up a
reverse proxy using apache which talks regular Shibboleth on one end and
can talk to Connect at the other end, using rather simple php based
authentication, user and group provisioning scripts. The scripts use
common federation attributes to do the provisioning.
As the backend of this module is technology neutral, it could in
principle be used to handle this kind of thing for any web based
application, as long as there is some way of provisioning with a
scripting language. Ideally this tool could be used to 'domesticate'
applications to be able to handle federated logins and group relations
without actually having to modify the applications themselfs. We still
need to test this for more applications to see how this works out.
* Created a federated solution for handling XMPP based instant messaging
and presence. (Note that we did *not* federate XMPP itself, sorry Josh).
A federated IM client can now talk to OpenFire, creating a high(er) LOA
for users at that server. Provisioning of users and groups is also done
in real time. Next thing would be to 'federate' XMPP servers to create a
trust relation between these servers, e.g. withing the SURFnet
institutions. This could however be done with more 'traditional' means.
* Implemented a domesticated OpenSocial container based on Apache's
Shindig. This container is now provisioned using federated attribute s
and group relations. External widgets and gadets used in the container
can use the provided attributes and group relations via the OpenSocial
API. We noted that federating widgets/gadgets turns out to be very easy.
When the portal (in our case Partuza) also made to requires federated
access, SSO between the portal and the widgets works very well. As
people, groups and a whole bunch of other stuff is already available in
the OpenSocial API, no provisioning is required for any of the widgets
and gagets.
The project will run until the end of this year. Other stuff on our list
includes, among other things: introducing group relations info Foodle,
on the fly provisioning of users and groups in Google Apps, hooking up
MyExperiment.org, domesticating FileSender, start using the recently
created SURFfederation<->openID gateway to connect to external services,
implementing a number of services already domesticated by the COManage
team, including Sympa and Confluence.
See you in Rome,
Regards,
Niels
Joost van Dijk wrote:
Hi list,
Here are the highlights for SURFnet:
* We are participating in the Microsoft Geneva TAP (Technology Adaption
Program), where we validated interoperability of ADFS 2.0 (formerly
Geneva) server with SURFfederatie and wrote initial documentation for
connection to SURFfederatie. We are in the process of testing Sharepoint
with a Geneva STS as RP to SURFfederatie, and connecting to the Live@Edu
Outlook services.
* PoCs: We did some Proof-of-Concept projects related to our federation:
Cross-Layer Identity, where we try to reuse eduroam authentication for
authentication to federated services using Kerberos TGTs (work-in-progress).
Web Services: we used a Security Token Service (STS) to enable web
services using federated identities. This has a very limited impact on
our federation 'core' (gateway), as we use a product (pingFederate) that
features an STS. More work remains to be done, esp. client-side.
We've also taken a look at User Centric Privacy. Later this year we'll
investigate usability issues. A student did a MSc. project combining
assertions from multiple (trusted/untrusted) IDPs.
* TCS: we've started using the new TERENA SSL service last summer. Over
50% of our customers have now migrated from Globalsign to Comodo, and
we've issued 400+ certificates so far (and we really love Kent
Engstrom's RA app that makes life so much easier)
* TGCS: During the meeting in Rome we're also setting up Confusa - the
software that will be used to issue TERENA grid certificates
See you all in Rome,
Joost van Dijk
SURFnet
