1 / 18

Middleware CAMP Day 2

Middleware CAMP Day 2. Current Research. Research that develops th e…. Multicampus Issues. System-wide Identifier  some established (CU), some working toward (UC)  currently trying to map various IDs, some see as impossible (UT)

depriest
Download Presentation

Middleware CAMP Day 2

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. Middleware CAMPDay 2

  2. Current Research • Research that develops th e…

  3. Multicampus Issues System-wide Identifier  some established (CU), some working toward (UC)  currently trying to map various IDs, some see as impossible (UT) System-wide directory including common definitions and common content management                 -       most see as impossible which implies need to provide interfaces, etc  -                -       CalState has working group to build system-wide directory infrastructure that includes multiple directories that appear unified using agreed upon common standards (LDAP, eduPerson, etc)                  -       CalState, UC, and CU have system-wide “eduperson” and campus-specific ‘eduPerson”  so key aspects centralized while not undermining autonomy (ie, CUeduPerson, BoulderCUeduPerson?) System-wide registry used at CU to help with interfaces to multiple directories  CalState using referrals rather than system-wide registry

  4. Multicampus Issues - Authentication • SSO  need to allow access to resources on another campus • PKI - implementing at UC, attempting at UT for fiefdoms on Austin campus;  plan at UC=one CP for system, multiple CPS=unique for campuses • Shib may be answer for intra-campus as well as inter-campus for systems as well as inter-systeme.      How to capture identity initially  methods and level of assurance vary from campus to campus

  5. Multicampus • Finding the convincing drivers is critical to cooperation and forward progress (key issue for UMass system and others) • Some examples identified - access to library resources (CU,others), distance learning (U Alaska), access to administrative systems (benefits  UC) •  Many identified in Business Case for Middleware on I2 website could apply to systems as well as individual campus • Education is also critical  need to reassure campuses not removing authority over data and data maintenance

  6. Interrealm in the intrarealm • Trust between security realms as much political as technical • Keep accounts separate from people; try to normalize id use at the application regardless of the account authenticated against • Identity mapping centrally • Directories – use of enterprise directory easier than security, learning to delegate which permissions to departments hard, especially with AD • Most campuses have started to centrally manage much of the AD world.

  7. From the applications developer view • If your web application does authentication, it's broken and you should fix it. Authentication is very well understood, and applications have no business messing with it. • The data is the most critical component. If apps developers don't know how the data works, it's hard for them to know how to make good use of it.

  8. From the applications developers… • There are many drivers for alumni authentication, therefore for alumni in directories -- e.g. lifelong email (many schools), selling stuff to alumni (Penn State), online alumni elections (Princeton). • Re the are-these-two-people-the-same-person problem, "it comes down to identification...you cannot fundamentally identify a human being in any way" -- the best you can do is to try to make it more likely that people already in the system will get flagged when they're brought in again.

  9. There are so many ways to do resource discovery… • resources to be discovered: • identity, i.e. people • directories • services, i.e. printers • dns service • h.323 or sip.  callees. • video archives • vc

  10. Resource discovery • two flows:  • 1) registration to resource discovery server  • 2) resource discovery server to clients • access controls needed on • both who can list themselves • and who can access this list • access controls should be tailored to fit the resource, e.g. search engines needing no access control from either side, but the dean's printer being protected

  11. Current resource discovery approaches • uddi • dns srv records • ldap • google • xns.org

  12. Research computing • Research about core middleware • authorization, security, resource discovery, video, N-Tier problem, etc. • Research about systems to support scientific research • Grids, digital libraries, peer-to-peer, others • Research about how to adapt those systems to individual science needs • GRYPHEN, Euro Datagrid, NEES, etc

  13. The frontier of core middleware • Authorization, authorization, authorization • Building a federated trust model • The N-Tier Problem – portals and middlemen • Affiliated directories • Identifier crosswalks • Enabling PKI – directories, path processing, digital signature validity

  14. Authorization, authorization, etc. • Expressing permissions • Expressing requirements • Transporting permissions • Obtaining and processing permissions against requirements • Digital rights managment

  15. Building a federated trust model

  16. The N-Tier Problem: portals and middlemen

  17. Affiliated directories

  18. Enabling PKI – directories, path processing, digital signature validity

More Related