...
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
...
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.
...
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
...
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
...
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
...