From: Arlene Allen <arlene.allen@isc.ucsb.edu>
To: Dede Bruno (Contractor) <Dede.Bruno@ucop.edu>, Wu, Albert <albertwu@ucla.edu>, David Walker <DHWalker@ucdavis.edu>, Mary Doyle <mdoyle1@ucsc.edu>
Subject: first stab at the objectives of the user provisioning
Date: 06/28/2010 06:05:40 PM
Ok, I'm thinking that our first pass would state the functional
criterion we expect to honor when piecing together our first pass at a
technical design. Can we just make this a chain note and add what you
think is missing? I'm thinking we add details to the wiki when they are
less volatile than the typical initial discussion.
The User Provisioning Process
1) The same codebase can run in an arbitrary location (campus) as long
as prerequisite resources are available to it. Define those resources.
2) The codebase can run successfully with zero customization OR it can
be tailored to successfully front end a particular SP it is being
customized to represent. Such a customized front end to a particular SP
would also be capable of running unaltered in arbitrary locations
(campuses). This excludes customizations associated with branding.
3) Since this project is contextual to UC ITLC, it is both acceptable
and prudent to build inherent knowledge of UCTrust technology into it.
Stated differently, it does not need to be agnostic to Identity
authentication processes currently in use, nor does it need to be
agnostic to the general organizational architecture of the UC.
4) There are three mandatory parties involved in this workflow and an
arbitrary additional number of parties to the approval process.
Mandatory parties are:
Functional service initiating the process of adding a
previously unknown person to an SP's internal repository with the
associated attributes and permissions. This is the incep point of the
workflow.
The specified IdP with pre-existing knowledge of the personal
identity being added to the SP's repository, i.e. this is a pre-existing
identity, somewhere. Might be in multiple IdPs.
The person in question being added to the SP's repository. I'm
thinking we assume some permissioning for attributes the SP requests.
This finesses the IdPs not doing it.
4th through n'th parties are any secondary approvals beyond
the three basic parties, and also the possibility of an attribute
repository that is *not* IdP in nature.
5) The basic flow assumes that all such provisioning starts with a
business process that involves the delegation of authority. For example,
no one is ever part of a financial system without being specified by
another person that is already a member of that system or a delegated
admin thereof. There is always a chain. I am not a believer of job
descriptions, interpreted by RBAC processes, that inherently imply
certain authority without human intervention. I would opine this is now
mainstream thinking in Identity circles. Please object if you do not
accept this !!!
6) Decoupled presentation technology is pretty widely accepted, but I'm
stating it here anyway.
7) What ever technology is chosen to implement this should be somewhat
ubiquitous. It is acceptable for that technology to have one or more
general prerequisites that are reasonably easy to meet. This is a rather
vague statement, and I assume it will be arrived at via consensus rather
than anything more formulaic in nature. Example: C language in a variety
of IDEs is good. Ada, Algol, Spitbol, Lisp, etc. are bad. This is *not*
a vaguely worded requirement to force the use of Java. Think browser
standards here. There is no such thing as a truly universal answer.
8) The process will, by definition, be handling some amount of PII type
data. For adequate security in a peer to peer type environment, we need
some form of code signing that assures this process has not been
tampered with.
9) All communications pathways must be appropriately encrypted.
10) No application layer process ever sees or has access to a password.
Passwords must always be handled by trusted third party authentication
technologies. We might see an implied violation of this in the vendor
software itself that is the heart of the SP functionality. We will need
to talk that scenario out.
11) There needs to be a designated code repository for sourcing and
security purposes.
12) The minimum acceptable scenario for proof of concept is that there
be at least one SP and two IdPs.
13) The only middleware technology specifically implied here is the
workflow engine. All of the above could be done without an ESB.
Question: Do we want to force more than the workflow engine?
Feels like a start. Please add your material and your objections.
arlene
--
Arlene Allen
Director, Information Systems & Computing
University of California, Santa Barbara
Office 805.893.2062
Cell 805.451.7471