Mini meeting to discuss lightweight accounts and Cosign

Date: 24/4/2007
Location: BP Seminar room
Present: gdmr, sxw, cms, neilb, toby

Sort of Agenda

  1. What do we want to do about implementing lightweight accounts locally? Cosign-friend or a separate kerberos realm?
  2. What are the issues with using EASE?
  3. Given that there'll have to be some kind of central account-allowing "I-have-read-and-agree-the regulations" service, can we piggy-back off it to avoid having to do our own?

Sort of Minutes

In the sort of order we discussed things:

3. We didn't discuss if we could technically use a central "I've read and agree the regulations" service, but we agreed that we should if possible.

2. Simon explained why we can't just use EASE or the eVisitor central services for anything other than EASE only web services. If we wanted to try and do cross realm, ie a web service wanted to allow DICE authenticated or EASE authenticated users, then it can't be done without significant changes to Cosign which are unlikely to be accepted upstream.

Though Simon did say it would be nice to talk to the EASE people to see what can be done in the longer term to allow this sort of problem to be solved properly.

The other option is that we stop providing our own KDC and use the EUCS instead. Though this is technically possible, there are political reasons why this won't happen (certainly not in the short to medium term).

1. Cosign only solves the pure web application authentication problem. It doesn't solve the "other protocol over HTTP" problems, eg svn+http.

A vanilla Cosign friend service, the likely lightweight solution, doesn't allow any delegation of principles to the thing behind the web service, eg we couldn't let a "friend" connection access a kerberised service behind the web service, eg get AFS tokens to browse AFS space.

A solution to this is to replace the standard MySQL backend to the friend service with a KDC in a separate realm. This would also allow us to tell registered "friends":

Hey you can do "kinit name@FRIEND.INF.ED.AC.UK" and get a genuine kerberos ticket.

This would then allow them to access other kerberised services, eg svn+ssh, or then getting AFS tokens.

Note that we need to start thinking about services being closed boxes, so in the svn example, the service can have its own uids and idea of "home directory" for users. As they should be interacting with it only via the svn protocol.

This is the route we are going to go down, ie Cosign friend, with a KDC backend. Simon is going to look at the code to see what work is necessary.

Other things

Things I think we discussed but don't remember where they fit.

Simon suggested that at some point we (Informatics) should sit down and revisit what it means to "have an account", and what it is that makes a light weight account become a heavy account. Is there even something that does this? And perhaps the whole account management tools need to be revisited, they were fine for the problem at the time, but now are perhaps not the way we want to do things.

Given the above, why do we want two KDC realms, why can't eveyone DICE and Visitors go into !@INF.ED.AC.UK? Are there a technical reasons, or is it just a good safety measure.

Also, a Wiki topic which I found, it is old but related LightweightAccounts.

Simon also mentiond an old document of Tim's that explained why we couldn't use the cenrtal auth (and EASE), perhap we should resurrect that and put it here. I found the original Cosign propsosal, http://www.dice.inf.ed.ac.uk/groups/infrastructure/authorisation/cosignproposal.html but that doesn't have much detail about not using the central service. Update Tim has since forwarded me this page ease,html though (as Simon also said) not all the points still apply eg point B1.

- NeilBrown - 25 Apr 2007

Topic revision: r2 - 26 Apr 2007 - 09:19:49 - NeilBrown
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies