DICE development projects - sxw

OpenID Identity Provider

boss — Fri, 25 Jan 2013 15:45:46 +0000

Project ID:

Current stage:

0_Pending

Manager:

sxw

Unit:

inf-unit

What:

Description: Provision of an OpenID identity provider would allow Informatics users to authenticate automatically to external websites whilst they're authenticated to the Informatics cosign service

Deliverables: An OpenID Identity Provider, integrated with our cosign serviceq

Why:

Customer: All users. Originally suggested by Henry Thompson at the Web innovation meeting

Case statement: OpenID is the emerging standard for federated identity assurance on the public Internet. Providing an OpenID identity provider allows Informatics users to participate in the OpenID identity federation, without creating dependencies on external providers. It allows easier use of external loosely authenticated sites.

When:

Status: A proof-of-concept Identity Provider has been deployed on duffus for a while. This project would take that provider and turn it into a production service.

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan:

Other:

Dependencies: Our cosign service

Risks:

Milestones

Proposed date	Achieved date	Name	Description

"Friend" lightweight authentication system

boss — Fri, 25 Jan 2013 15:45:43 +0000

Project ID:

Current stage:

5_Completed

Manager:

sxw

Unit:

inf-unit

What:

Description: Develop a lightweight authentication system, similar to (or based on) the cosign "Friend" system, to allow users not affiliated with Informatics to authenticate to our systems.

Deliverables: Additions to the authentication system to support lightweight accounts. May also require authorisation system changes, to support authorising lightweight users.

Why:

Customer: services-unit, and anyone else deploying systems which require lightweight accounts

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources:

Plan: We can choose two possible options for this:

*) Deploy the UMICH cosign Friend technology, which will only allow friend authentication to web-based services, which don't rely on using delegated credentials with backend systems

*) Deploy a Kerberos based solution which uses a new realm - FRIEND.INF.ED.AC.UK, with a seperate KDC, and uses cross-realm authentication to provide friend based access. This has the advantage that is far more flexible - and would allow us to provide 'friend' access to non-web services such as AFS.
However, it would require writing our own code.

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description
2007-07-30	2007-08-06	ifriend-master-	Create new KDC for friend principals
2007-08-10	2007-08-13	ifriend-web-int	Produce web interface to allow the creation of iFriend accounts
2007-08-03	2007-08-20	ifriend-cosign	Modify cosign service to accept iFriend accounts
2007-09-04	2007-08-24	ifriend-backups	Create backup arrangements for friend service, including enabling a slave KDC

Improve Host key management (subsumed into "wallet" #129)

boss — Fri, 25 Jan 2013 15:45:43 +0000

Project ID:

Current stage:

4d_Dropped

Manager:

sxw

Unit:

inf-unit

What:

Description: Improve the host key management system (kdcregister & associated utilities) so it no longer has dependencies on non-public MIT Kerberos header files

Deliverables: A host key management system that doesn't depend on non-public Kerberos header files

Why:

Customer: Requested by the MPU

Case statement: Summary - how do we manage kerberos keytabs for "inf" level machines.

Current situation
-----------------
The "inf" level serves two purposes :-
1) a minimal development environment for MPU unit working on new platform
releases.
2) a means by which we can support legacy (or even additional) platforms
against DICE services, in a lightweight manner

The current "inf" level does not include kerberos host key creation
at install time. Instead, host keys are created in a manual process and
not necessarily for each machine. This is because the current implementation
of "kdcregister" relies upon kadmin interfaces which MIT have made private in
recent releases. This complicates the build process by requiring locally
built Kerberos RPMs in order to build kdcregister.

However, we have at least a couple of concerns with the current situation.
Firstly, one can't securely authenticate a user at login unless the
machine has a kerberos keytab. There's no trust path between the machine
and the KDC, which means the machine can't check the validity of the
response that its given. The only reason this still works for us is that
we're using an outdated pam_krb5 binary - when we upgrade this, Kerberos
logins to keytabless machines won't work any more.

Secondly is that we still have a long term plan of using LCFG
spanning maps to control which service principals can be issued (and to
delete those which are no longer in use). The adhoc creation of keytabs,
by running kdcregister manually, or by directly invoking kadmin, would
complicate the realisation of this cunning plan!

When:

Status:

Timescales:

Priority: Relatively low priority, as the current kdcregister mechanism has been successfully ported to the FC6 and FC5/6 x86_64 platforms.

Time:

How:

Proposal:

Resources:

Plan: We propose that in the medium term "kdcregister" is reimplemented using
a more portable and supportable technology.

We have a number of options here.

The simplest, quickest and lowest risk would be to reimplement kdcregister
using the same transport technology as the current X509 server certificate
signing system, sixkts. This a known local technology, which would have a
small implementation cost.

A more ambitous plan would be to investigate redesigning the entire mechanism
by which secure content is distributed to our machines, encompassing a
possible replacement for sixkts, as well as the systems for distributing
keytabs and SSH keys. To do this we'd deploy Stanford's remctl program, along
with their wallet technology. The primary benefit of this would be reducing
our dependence on a locally written protocol in a security critical role, but
it's not clear that the eventual result would be worth the development risks
involved.

A futher possibility is to work with MIT on defining the kadmin API in such
a way that they are prepared to support it as a public interface.

Meanwhile, kerberos keytabs should be created, manually, for all "inf" level
machines and appropriate "kerberos.keys" resources be set to flag machines
with active host keytabs.

Other:

Dependencies: If we decide to work with MIT on refining the kadmin interface, we are
depedent on their argreement, and release management processes

Risks:

Milestones

Proposed date	Achieved date	Name	Description

System Monitoring

boss — Fri, 25 Jan 2013 15:45:34 +0000

Project ID:

Current stage:

5_Completed

Manager:

sxw

Unit:

inf-unit

What:

Description: Deploy a monitoring system configured via LCFG resources. In stage 1, this system will purely monitor the AFS service, stage 2 will expand this to being usable by all service component authors.

Deliverables: Stage 1, a monitoring service suitable for monitoring the availability of the AFS file and database servers

Stage 2, a monitoring framework capable of extension to monitor any LCFG configured service.

Why:

Customer: In stage 1, the AFS system managers.

Stage 2 will open this up to the entire CO community. Better notification of system outages, and the collection of uptime statistics will also improve the service we provide to end users.

Case statement: Monitoring within DICE is currently done in an extremely ad hoc fashion, where it happens at all. As we deploy more and more critical services with redundancy built it, it becomes vital to know if these fail. Redundancy can hide initial service failures, until the final redundant system falls down, and the entire service fails.

In particular, AFS has a set of redundant database and file servers. It is important to know when one of these go down, as the system will continue regardless of server failure.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal: A detailed proposal was circulated to COs in December 2005, following investigation of a number of different options for monitoring technology and configuration approaches. We will deploy Nagios, and use a configuration system which directly fetches profile information from the LCFG servers to manage host configuration.

It was proposed that the development be undertaken in two stages. The first stage will produce a system capable of monitoring all AFS database and fileservers.

Stage 2 will extend this to produce a framework capable of monitoring any service configured through LCFG, by providing a means for component authors to write monitoring scripts based on their component's resource.

In order to increase the utility of monitoring messages, initial service failure notifications will be provided via Jabber, using presence to avoid sending notifications to users who are unavailable. Escalation via email will also be provided.

Any other notification methods, such as SMS or pager are outside the scope of this project.

Resources: Simon's time (which is pulled in many different directions ...)

Plan:

Other:

Dependencies: If we wish to offer reporting via Jabber, a production quality Jabber service will be required for COs.

LDAP schema changes are required to support Nagios user configuration

Risks:

URL: https://wiki.inf.ed.ac.uk/DICE/MonitoringProject

Milestones

Proposed date	Achieved date	Name	Description
2007-05-28	2007-05-25	sysmon-jabber	Deploy production version of required notification service (Jabber) Depends upon services-unit making hardware available
2007-06-25	2007-06-20	sysmon-codecomp	Code complete, tested and deployed on development hardware
2007-12-05	2007-10-03	sysmon-afscomp	AFS component rewritten to actually configure AFS services, and therefore be monitorable. This milestone transferred to the AFS project.
2007-07-23	2007-07-01	installhardware	Hardware for production service installed. Date depends upon hardware delivery, and time availability within inf-unit
2007-07-27	2007-07-01	sysmon-prodcode	System moved to production machines. Date depends upon installation of production hardware
2007-11-05	2007-09-07	sysmon-slave	Install 'backup' slave monitoring system
2007-09-07	2007-09-07	sysmon-doc	Produce documentation on how to write a monitoring component