Assorted jottings on the Lightweight accounts problem, with a view to actually implementing something in a shorter-than-geological timescale.

Meeting minutes

http://www.dice.inf.ed.ac.uk/groups/user_support/accman/meetings/2003-11-10/minutes.html contains the minutes from the meeting in which we thrashed out the details of how lightweight accounts should work. Few of the actions from this year-and-a-half old meeting have actually occured.


Simon's note: I'm not sure that some of the conclusions we reached are valid:

  • Placing 'EdUni' lightweight accounts within the People tree is over complex - either someone has a UUN and gets a 'full' DICE account, with whatever capabilities we want to give them, or they get a 'lightweight' account based on their Email address

  • Using the AMT package to maintain lightweight accounts seems like overkill. If we're going to allow their creation through a web tool, then we should configure maintaince activities through that same tool.

Notes from emails to Paul

Some jottings from emails between Simon and Paul in November 2003


Yes. We're going to refactor things to remove the association between 'account' and 'identity'. In the examples above you don't care whether the user has an 'account' in the Unix sense of the word, you just want to be able to establish an 'identity'.

So, we'll have identitys which are purely an LDAP object and a Kerberos principal. Remote users will be able to establish one of these identities by filling out a form, and proving their email address. You (as a service provider) can then use the standard DICE authentication mechanisms to establish the user's identity, and make your authorization decisions.

Unfortunately, lightweight identities aren't quite identical to DICE identities, with the account removed. The name of a lightweight identity takes the form of the user's email address with the @ changed to a percent. So, I would be simon%sxw.org.uk. This means that there are certain things you can't do with them (turn them into full blown accounts, for instance).


Actually doing an implementation is relatively trivial.

There should be a web service which the user uses to sign up, which sends an email to their email address containing a 'confirmation' link, when that confirmation link is clicked, account details are created in LDAP and in the KDC. Probably about a days worth of coding (at most).

The problem is that the account management team want to integrate the creation process for lightweight accounts into the account management system. This is a much bigger task, as the account management system is fairly heavyweight, and really geared to handling items in the 'People' tree. It's also not been written to support remote invocation.

More recent thoughts

Do we require some kind of sponsorship arrangement? The outline above allows pretty much anyone with a valid email address to create an account in our KDC/LDAP server. The overheads of this may well grow to be fairly severe. A sponsorship scheme would require anyone applying for a lightweight account to have someone with a DICE account sponsor them. This sponsor would have to confirm their approval by visiting a kx509 protected web page, before the lightweight account was enabled. We'd then have to have some kind of expiry mechanism, and an easy way for sponsors to view all of the lightweight accounts that they're responsible for, and to add/remove access from these.

-- SimonWilkinson - 03 Apr 2005

Another consideration

Given lightweight accounts (identities really) won't have login access to any desktops and we might end up with a lot of them should we consider not replicating that part of the tree onto all of our clients by default and only replicate onto those machines offering services that require them?

-- TimColles - 07 Jun 2005

Topic revision: r4 - 22 Nov 2005 - 10:27:01 - MornaFindlay
 
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