8/12/2011 Conference Call Notes 4-5pm EDT
Attendees
- Rob Carter, Duke University (convener)
- Keith Hazelton, University of Wisconsin, Internet2, Bamboo Project
- Tom Zeller, University of Memphis, Internet2, Unicon
- Lucas Rockwell, UCSF, UC System
- Introductions
- Rob: Duke University - convener (because Tom Barton didn't want
Keith to leave Chicago with two groups to convene
- Keith: Wisconsin and Internet2, but heavily involved in IAM needs
of the Bamboo Project, and willing to try out our ideas with
the Bamboo participants as that becomes possible. - TomZ: Memphis, I2, Unicon – working with both the Grouper project
and the Shibboleth project, with strong interest in how SAML
may play in this space - Lucas: UCSF and the wider University of California system, which is
looking for system-wide solutions in the IdM space now
- Agenda bash
- Rob: We have roughly one month to produce a report back to the larger
group from Chicago, so we'll need to make some quick progress in
framing up the problem we're presented with. To that end, the
first call's agenda includes discussion of goals for the next four
weeks (putatively, framing the scope of "provisioning" in this
context, refining a gap analysis within that scope, and developing a
high-level solution strategy for the space that we can advocate to the
wider Chicago group. We also need to consider organizational
matters, and look at setting some very short-term objective as AIs
for the next call (probably in a week). - There was general agreement to the agenda as proposed.
- TomZ: will have to leave around 4:30 ET for another engagement.
- Scope
- Rob: Should we take a few minutes to discuss the background from the
Chicago meeting, since Lucas wasn't able to be there (just to make
sure we're on the same page)? - Lucas: would find it helpful
- Rob: Shall I take a stab at it, or would someone else like to?
- Keith: wanted to hear Rob's take on the meeting
- TomZ: Go for it.
- Rob: In overview: A bunch of us realized that lots of our institutions have
critical needs in the area traditionally addressed by commercial
products that call themselves "identity manager" solutions. Many of
us are either looking for solutions because we've reached the point of
needing better support in this area. Many others are shopping for
alternatives in the aftermath of the Sun/Oracle merger. Many schools
have done home-grown solutions in the space (mostly only
addressing their own most pressing needs) but have found little in the
way of shared open source alternatives. Meanwhile, some larger
open source projects (notably, the Kuali project) are reaching the
point in their lifecycle at which they need to address IdM issues
and are considering development in the space. Some of us agreed
that it might be worthwhile to get together and see if some cooperative
effort might be possible in this space, and if there might be some
points of convergence we could take advantage of.
In the discussion, we ended up identifying about eight high-level
components of an IdM stack that we felt were significant for higher
ed. After a prioritization exercise, we settled on three technical and
one organizational priority to try and address first, and formed sub-
groups to start considering each one in greater detail. The top three
technical priorities were:
- Registries. Our sense of this space was that it would
encompass the part of an IdM stack where source data
(probably coming in from multiple authoritative sources)
would be collected, stored, merged, deconflicted, potentially
used to synthesize additional identity data (roles, for
example). We pluralized the word in recognition of there
potentially being multiple registries – users, clearly ,but
possibly other types of identities, as well.
- Access Management. Our sense here was that this group
would think about how the identity information in the
registries gets translated into a form usable for making
access control decisions, and how systems that need to
make those decisions interact with the data in order to make
them consistently and quickly.
- Provisioning. This is our present group. In the Chicago
discussion, there were actually two distinct areas discussed;
provisioning and data presentation. The distinction
between them was largely the distinction between "push"
methodologies and "pull" methodologies – "provisioning"
was used as a proxy for the "push" methods – ways in which
data in the IdM (in the repositories) would be pushed out to
other systems (perhaps in the form of account creation,
perhaps in the form of data synchronization, or perhaps in
other forms). Data presentation was to some extent a proxy
for "directory services", although it frequently was discussed
as including things like query APIs. One of the questions
we will need to answer is whether our view of provisioning
will scope the "data presentation" portion of the space
in or out of view – it could easily be considered part of our
scope, or as a separate issue all to itself.
- Lucas: background was helpful – just to clarify – which of "push" or "pull"
are we saying is definitely in scope? - Rob: I think "push" is automatically in scope for our discussions – if we
want to also discuss "pull", we can, but if we want to limit ourselves
to "push", it's probably OK for us to do so. - Keith: Would hope that pull can be in-scope for us. SCIM has both push
and pull semantics defined for its approach. Also, is it in-scope to
discuss as part of provisioning how we get data into the
provisioning engine – whether we use hand crafted connectors for
each source system or somehow try to standardize an interface for
incorporating data into the engine? - Rob: A good question – I could see two different questions, really – one
around whether the provisioning engine takes data only from
the registries (where it may have arrived from lots of other
source systems) or whether the provisioning engine takes data
from source systems as well, and one around whether the
input of data to registries is par tof the registry discussion or
part of the provisioning discussion. I could see it going either
way, logically, although I have a bias (coming from an OIM
background) for separating the two into provisioning (which
just covers the flow of data from the registry to other systems)
and reconciliation (which is Oracle's term for the loading of
data into the registry). The two can certainly be treated as a
single whole, though. - Keith: Right - both are possible, and architecturally, it's just a box with
an "in" side and an "out" side. - Lucas: Calling out the difference between the two is important and useful.
Provisioning (IMO) is more geared toward getting data from the
registry to subordinate systems, not necessary getting it back to the
sources. Data synchronization is perhaps another phrase for it. - Keith: In the end, our goal is an open source IdM stack that works, so
the interaction between the registry and the provisioning engine is
critical – input to the provisioning engine has to be addressed from
one of the two sides (whether by the registry folks or by us). Getting
source data into the registry to begin with is another issue that's
distinct, but… - Rob: Agreed – regardless of anything else, the interface by which data
gets from the registries into provisioning tools/services is
critical, and needs to be negotiated between us and the
registry folks, no matter what. Depending on our and their
opinions, getting data into the registry could be construed as
just another kind of provisioning task (this time from a source
system into the registry). - Keith: Right – the same tools could be reused there potentially, but what
we're really worried about at this point is the interface between
us (provisioning) and them (registries). - Rob: Since Tom needs to leave soon – did you have any early thoughts to
add before you have to go? - TomZ: A picture would be useful – even if really simple and really high
level – to describe what we're talking about. it should
include both push and pull mechanisms, and should mention
moving info around within the organization across the
different components. It should include provisioning within
the organization as well as across federations and into the
cloud. We can use the wiki to house some of this initial
documentation. In Cicago we talked about sending a message
to folks to describe what we're doing – ti would we worthwhile
to poll people outside the group about what they're doing in
this space – Surfnet is working on some stuff with a group in
Finland, UNC-CH did some work with SPML not too long ago,
some folks from the EU seemed interested in an approach
similar to what we're doing (an open source IdM "stack"). If
we put together a picture and distribute it, then we can use it
to poll and see who's interested in the space and who's doing
something already that's of interest to us. - Rob: Definitely worthwhile to get a picture early on.
- Tomz: Niels from SurfNet has a good picture in this space – I can
find a link and forward it to the group. SCIM has some good
documentation of information flows as well - Keith - the SCIM link should be out in email to the group – perhaps good to
go review the SCIM model and see where we think it might
fit or not fit in our use cases. - TomZ: SCIM has gone a long way but has a few gaps left to address – its
primary gaps are probably in the area of handling merges of
identities (editor's note: I'm guessing this referred to what
we at Duke call "consolidations" – where one individual ends
up with two identities and needs to have them collapsed into
a single identity?) Also there is work toward developing a
concept of roles and entitlements in SCIM – Chris (editor's
note: Which Chris?) is advocating they consider both
roles and groups… Their strategy on and position around
entitlements isn't as clear yet… Perhaps we can provide them
clarifying use cases in some of these areas. - Keith – That's definitely concrete, and worth some effort. It's not clear if
SCIM will catch on or not, but we can at least bet on it and
to give them good advice when we can. Perhaps take as a
a goal tracking the SCIM project and providing input on
the university / VO cases that drive needs for things like
merging and entitlements. - Tom – would be nice to work out some use cases using different solution
models – saml, spml, and SCIM – to show how they each
might work. In the end, there might be more than one type of
box in the middle. - Rob: definitely – we don't have to envision a one-size-fits-all
- Keith : Also something that we can discuss in the strategy group on the
next call.
- Tom had to leave the call at roughly this point…
- Rob: We should probably address some of the organizational questions
with our remaining time. So far, we've gone longer than I expected,
but the discussion has been fruitful. - Keith: The extent of discussion on this first call suggests we have some
of the right people at the table, at least. - Rob: Definitely – so discussing organizational trivia, do we:
(a) want a mailing list? - All: yes (Keith: archiving would be good too)
(b) want to use the same wiki page - All: yes (if we need ore pages
we can always create them
( c) Concalls weekly? - All: yes (given our short time frame)
(d) Concalls on this bridge at this time each week? All: yes
- Rob: Good enuf. we need to document AIs for the next call in a week,
then. How about:
+ *Rob: Take a first stab at drafting a picture of the overall
architectural diagram and how we fit in it.
Rob will use Graffle to produce a high level diagram*
+ *All: Review the documentation from the SCIM project, particularly
the SCIM scenarios documentation, and see where you think
there are gaps between our needs and the use cases/
scenarios SCIM is addresing.*
+ *Keith: Will send out URLs for the SCIM documentation and web
site for us to review*
+ *Rob: Will send out some other items for though before the next
conference call.*
At this point, we adjourned for one week, to return on the same conference bridge from 4pm - 5pm ET August 17th for a followup call. Expect emails during the week leading up to the next call.
;rgc