ISDA Leaders Roundtable Notes
4.14.08
A Middleware Unified Field Theory
by Michael Gettes
An idea, a suggestion, a way of looking a things.
Internet2 --> Stanford - Stanford has been sitting on it for 4 months.
MACE - group that does a lot of navel-gazing in this space
MGettes - not a believer in virtual organizations, not real
CO = Collaborative Organization
It's all about the App
Access, control to community
Great Plains Network - Entitlement Repository Protocol (ERP) --> not a single app spoke this protocol
graphic
Signet - open source priv. mgmt from Stanford (sponsored by Internet2) - unused
Grouper - UChicago group mgmt system
Jim - Signet similar to RolesDB, is it being used?
Mike - not right now, due to giant bug - info gets blown away every time an update is made (!!?)
DEMO: http://comanage.internet2.edu
ProtectNetwork - "identity provider of last resort"
Europe has its own, we may join it eventually
Front-end is completely modular to implementers
Mike updated LDAP dir info for his profile.
Paul H. - Authentication managed in a completely diff. system
MyIdentity - not really "your" identity, just copy disjoint from main system
Mike - You can set it not to be changeable for email etc. Implementer has control over user changes in system.
Grouper - scalable, can accom. hundreds of thous. groups w/ same no. of member in each.
direct member = user (i.e. not a list)
Group math is possible
Signet - priv mgmt. - delegate, assign privs, etc. (like Roles)
MyServices tab:
what's linked into this system
"When developers design"
Info. gets pulled from grp & priv mgmt systems & added to LDAP dir.
Confluence integrated into this env.
- Administration - Manage Groups - gets info real-time from LDAP dir
DimDIm integration
Federated Calendar - Bedework
- schedule across organizations
Barriers to membership/profile data - this model can potentially solve that problem - with enough work
Diagnstics - EDDY - unified, federated view of this info.
fudgie.org - that is so Matrix
COs with VOs integrated therein
Discussion:
Paul H. - may end up with many diff. co-managed systems - edit identity needs editing in many places
Mike - how data is managed - local policy decision - central or several profiles
Mary - each co would have several profiles?
Mike - yes, now COs don't allow users to update manually
Janet - had to change her name across many places, & some wanted to hear it from other authorized ones, so same issue here
Paul H. - every dept could run its own LDAP
Mike - decentralization, yes, but it could be going too far
Landry - plan is to roll out VM image to a lab with all the hooks in place to plug into central
MIke - we need to make sure we have the necessary components for the hookups
Craig/Mike - is the LDAP deployed once or nightly update? you deploy LDAP once, all else are live updates
NERCOMP talk from Brown - they do it nightly
PC = provisioning connector - runs every 90 seconds
MIT's current = 4 hours
Mike - wants "just to be a contrarian"
Jim - model for privs & auths that presumes that there's a small amt of these & simple model
Roles has tremendous amt of granularity & particular control over access
- you never expand these - b/c there are millions
- model is question-based
- if we eliminated the $$ component, it could work
Paul - in LDAP you can set access control for limited access to subsets
Jim - to make it practical, we would have to
Craig - what this is is what we need for Stellar & content collab. Provide LDAP to provide 3rd party apps that read LDAP.
Mike - too simple, we need to provide info reliably to LDAP
Craig - working backwards from the app, we need that
Landry - we need abstractions over those systems so we can plug things in
- LDAP would act as surrogate interface for Roles, etc.
Mailman - can we make it speak LDAP
Paul - build the connector, go from 1 type of member to 4 types
- build ldap.mit.edu
- build connector for Roles for small subset of auths, no expanding
Landry - so LDAP is a protocol
Paul - don't want to implement own library - no LDAP front-end to Moira
Craig - things exist to make that happen
Mike - have a proxy in place without "sporting" an LDAP interface on an App, hide the complexity of LDAP env - large-scale, fast
- some apps may not be able to keep up with speed and complexity of LDAP env.
Paul - have to adhere to schemes & standards, reworking needed over & above any "interface"
Mike - are all these services separate? from user view they are all one
Jim - Roles has 3, including groups
Landry - students svcs apps have means of writing back to enterprise apps, abstraction of MIT infrasctructure, with just the app interface
Craig - we want to store user data off Stellar DB's and access a subset of it to show users for their updates, again, native UI for Stellar
Mike - groups is a poor man's roles/perms system
Paul - audit-free system
Craig - he just wants to worry about lists, users just want to worry about granting access to other users
Mike - there's important functionality that must be accounted for on the back end so that the right input maps to the right permissions
Derek - it makes just as much sense to provide a single usable interface for users, disabling the multi-interfaces of various apps
- centralize it, rather than making it app-dependent
Mike - downside is that you lose app-specific nomenclature and namespace
Jim - doesn't think much was lost disabling auth granting in SAP & having it all happen in Roles
Landry - abstraction on the front end, translation on the back-end, so the interface is a standard SAP interface with the right things happening on the
back without being made the user's problem
Derek/Landry - we should endeavor to provide both app-specific & cenreal UIs for updating group members
Paul - we don't have ability to change that in our deployment of Conf, others do
Landry - we should have both, with central app being the "advanced" editing version
Jim - doesn't want to have dozens of places and shadow systems where people get left behind even if they leave MIT
Craig - Stellar, Conf not really built to do the sort of perms auditing that central svcs may
Mike - not resp of app to do audit
Craig - "this needs to be auditable, this doesn't"
Jim - convenience of app development/design isn't always what's good for the community
Janet - unified UI - Lycos - upside centralized - one acct, one ui
- problem when a site wanted special ui, look or requirements (Angelfire) - this was a speedbump
- there are benefits to both
- one solution was to make it skinnable
- central info has to be relevant outside of specific context
Derek - if you have a user who is not a moron, and the UI is usable, centralization is preferable b/c user will understand what is being altered
Joanna:
- make it generic
- make it simple
- communicate the implications/results of actions to the user
Mike - what does it mean to "translate it to MIT"
Craig - stipulating functionality and a timeframe, not a specific app (Moira)
Landry - what are the specific steps, how will it be different from what we have now
Derek - cost, resources how do do one vs. the other, instead of "philosophical discussions" of benefits