1 / 8

More Allergic Reactions Some Potential Next Steps

More Allergic Reactions Some Potential Next Steps. Tom Barton University of Chicago. 1. Authority Management aka Distributed Attribute Administration. All of a VO’s authoritative persons and participants are not collocated within a single administrative domain

jeaniec
Download Presentation

More Allergic Reactions Some Potential Next Steps

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. More Allergic ReactionsSome Potential Next Steps Tom Barton University of Chicago

  2. 1. Authority Management aka Distributed Attribute Administration • All of a VO’s authoritative persons and participants are not collocated within a single administrative domain • What attribute, group, & authority management systems and process will SoAs use to make their authority manifest in run-time infrastructure? • PERMIS, CAS, VOMS, … • Signet, Grouper, possibly in conjunction with above • Further work needed to determine reasonable ways of deploying the above • Maybe a cookbook 2

  3. 2. Name Mapping aka Account Linking • Bridge between deployed grid PKI and campus identity namespaces • Similar need seen in several architectural contexts (gridshib, myproxy, condor-shib) • Anywhere campus IdM and external IdM come into contact • Can we solve this just once? 3

  4. 3. Easing Design & Deployment • Reliance on formalized statements of practice that may refer to established standards of trustworthiness, and assurances that trusted IT operations actually do as they say • Examples: euGPMA, NIST, Federation attribute usage and operational practice profiles, CAF 4

  5. Easing Design & Deployment • Need more community standards • Providers & consumers of identity, authentication, & attribute tokens can be more easily implemented, across VOs supporting the community • Reduce, or at least bound, the potential set of “security profiles” (trust anchors & attribute profiles) our designs must support • Where can such discussions take place? • Egg, NISO in Library space 5

  6. Easing Design & Deployment • Technical architectures require sufficient campus identity & access management practices to actually support real activities • Better organization is needed to foster campus IAM deployment/upgrade 6

  7. 4. Low-Bar vs. High-Bar • Most(?) actual academic, multi-org spanning collaborations are informal, <10 participants, narrow scope (e.g., write a book). • Provide faculty with what they need to be at their best, but make it easy – Jeff Huberman • Is Jill’s MyVOCS exploring a sweetspot? • And is it in fact that easy, yet? • If not, what’s needed? • What about participants whose home org lacks sufficient IdM (or who lack a home org)? 7

  8. 5. The IdM Bump in the Rug • How to provide all participants with access when many are not already present in “blessed” authentication services? • K-12, unaffiliated persons, patients, affiliated persons whose orgs lack sufficient IAM practice • Preferred solution: someone else’s problem • Leif: analyze the cost of user support • Organizational solutions might help • Service centers • Develop or leverage a friendster.com like reputation system approach?? 8

More Related