Child pages
  • Minutes of the 8-12-2011 concall
Skip to end of metadata
Go to start of metadata

8/12/2011 Conference Call Notes 4-5pm EDT


  • 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 (smile)
  • 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.


  • No labels