Hi Heather, Ken,
Thanks again for the joined presentation @I2. I think the spring meeting
was very interesting and it was fun to be able to interact with your
community :)
In regard to Comanage, we are wondering in what way Internet2 and
SURFnet could work together. Things like: What would be the way you guys
prefer? What would be a practical way of collaborating?
Below are the things we came up with, please feel free to shoot on any
of these! Please also note that I cannot promise we can do all of it,
but within SURFnet there is a strong feeling that we should try to make
a collaboration on COmanage work given the fact that our goals seem so
much alike.
The following comes to mind:
1)Work on domestication of apps
This process can be done rather separately. Informing each other of what
apps we would like want to have could give us a shortlist of the most
interesting ones. Next either party could then go about and get the work
done, or even better, persuade builders of the app themselfs to do it
for us ;). We @SURFnet may be able to provide a financial incentive if
need be.
As you guys already have tackled some apps, it would be very useful to
have some sort of description of how to do this so that it best fits
comanage. Some practical and technical guidelines would be really helpful.
First some generic ideas on domestication:
- An idea/questing which popped up is that it might be an idea to create
a set of generic libraries for common languages like java or php, so it
will be easier for programmers who are not very farmiliair with comanage
to still implement 'domestication' into their app. As you already did
some work on drupal, it might just be enough to externalize the
libraries that are already created for drupal to tackle the php case.
Furthermore I know some work was done in the UK to create some libraries
for grouper stuff in php and .net if I am correct. Perhaps these can be
used as well?
- Another idea was perhaps to have a generic 'proxy' e.g. in php which
could sit inbetween the federated/comanage world and an app which has
webservices support for authentication and group(provisioning). This
again would be a more generic approach than having to dive into the apps
themselfs and adapt them. We actually already sort of did this when we
federated Adobe Connect and could make that solution more generic to
include group releations.
- Another thing would be that if comanage would like to support more
apps, having all of these apps in one vm might become a real problem to
still fit. Also some products might introduce conflicts, for example
because they introduce the same sort of functionality. Therefor a more
generic way of adding applications might be usefull. It might even be an
idea to have something of a 'wizard' for 'non-techies' to be able to
choose which apps to install. Such an approach would make adding apps
more easy as their is no need to have them all in place in the Vm to
start with, but can be downloaded 'realtime' during the install. Also
this would make it more easy to contribute apps by parties other than
I2. Both rpm and dep package managers could be usable to get that done I
think, but I'm no expert on that. In a hopefully not to distant future,
all that comange would need to do is introduce some form of compliance
testing perhaps...
Regarding the apps already on your roadmap:
- I noted phpBB. We already have a federated phpBB, but must inform you
that it is very ill suited to be domesticated as code for identity and
groups is very integrated into the product. However we do have a need
for a federated forum.
- Bedework would be very nice. Is work there still needed as I got the
impression from their presentation @I2 that they already have planned
federated access in the near furure. Perhaps groups needs attention.
- we would not mind Zimbra, although that would not be a priority for
us. We have a very able company here supporting zimbra for a number of
our institutions, who also have keen knowledge of access federations.
That might be an interesting match and perhaps I can convince them to
pick setting zimbra up for comanage, as they already showed in interest
in Grouper as well.
- Jira would be nice, not so much for our collaboration environment, but
because we would like to use that internally. I'll start poking around
to see if I can get a business case out of that ;)
- Furthermore we need document sharing. Alfresco
(
http://www.alfresco.com/), an functionally very mature open source EMC,
seems currently the most interesting candidate. Although this app has
the ability of externalizing some stuff (e.g. implementing CAS), Shib is
not yet there. Neither are groups. Webservices are available for
provisioning users and groups, and it has means of using external db or
ldap, so that would help. Having seen the confluence plugin, I feel that
something very similar might do the trick.
- Also our wishlist contains web/videoconferencing (could be
Adobe Connect, as we already know domestication is rather easy, but an
open source webconferencing tool would also be ok, eg DimDim or
Openmeetings). By the way what are your ideas towards addition of
commercial/proprietary products to comanage? I can image you will not
include these in an image to be distributed, but are there other objections?
- Finally presence is high on our list. However we see a lot of problems
given the fact that the standards in presence hardly support federated
authentication. Any ideas on that perhaps on your side of the Atlantic?
2) Work on COmanage itself
I feel that that would perhaps be somewhat more difficult. For example,
that would require some kind of shared code repository to be set up. On
the other hand, getting COmanage up and running on centos might be
something we would like as well. Also I already mentioned that we will
probably not run COmanage as a vm, as we would then need something like
10000 vm's. That would be rather inefficient. So we will take COmanage
and start splitting up the components over a number of servers. This
'scaling out' of COmanage may give interesting feedback for you guys and
we would be happy to document the procedures on how to do this as well,
so others can benefit from this.
3) User 'Portal'
Finally, we have the need for an 'entrypoint' to the apps which offers
more functionality than the current links that are provided. By the way
this is not meant as an negative comment on how you did this now, you
just needed a simple way of providing an entry point, which is clearly
ok for the first version of comanage.
We strongly prefer not to change the underlying apps. Something
mentioned by Heather as well if I remember correctly. So we are thinking
along the line of introducing a portal which could 'glue' the
applications, without the need for modifiing the apps themselves. For
example by providing widgets that present some kind of content delivered
by the apps in the back. This could be something simple like an rss feed
of 'the new documents of my team', coming from the documentsharing app.
If the portal itself is federation enabled as well as the apps, a user
can login to the portal and than seamlessly move between portal and
applications. As group relations can also be shared in between apps, a
user would already enter an application from the portal in the right
group 'context'. For the portal we would like to try using something
like openSocial. I noted that you already have some ideas on doing
'social apps' on the roadmap stuff as well, so I would be very
interested to learn your ideas on this.
Kind regards,
Niels
--
Niels van Dijk
Advanced Services
T: +31 302 305 337 / M: +31 651 347 657
SURFnet - PO Box 19035 - NL-3501 DA Utrecht - The Netherlands -
http://www.surfnet.nlSURFnet grensverleggend netwerk voor hoger onderwijs en onderzoek
