1. CARSI: Federated Identity and Resource Sharing over CERNET Dr. PING CHEN Peking University( 北京大学 ) Jan, 24 th, 2008

2. Agenda Current AAI Situation over CERNET Our Plan: CARSI CARSI Elements  CARSI Infrastructure  CARSI Federation Contract Negotiation & Audit  CARSI Federation Provider Registry  CARSI Virtual Resource Directory  CARSI OpenIdP  CARSI Services Current Deployment Current Focuses

3. Current AAI situation over CERNET Most Univ. have campus-wide IDM Univ. web applications run in two ways:  accessed publicly without protection  only be visited by a closed set of users Cross-univ. AAI is important to sharing  Sharing object can be user identity resource  Sharing object can also be web applications Cross-univ. AAI and resource sharing is still in the experimental stage

4. Our Plan: CARSI Cernet Authentication and Resource Sharing Infrastructure Goals:  To integrate university IDMs to a CERNET AAI  To share univ. user account resources over CERNET  To share existing protected web application resources from a closed set of users to CERNET users  To protect existing unprotected web applications  To provide a basic AAI middleware for CERNET applications  To standardize and simplify application’s upgrade to AAI- protected  To push new applications cross universities

5. CARSI Elements: 1. CARSI infrastructure  Based on SAML/shibboleth 2. CARSI FCNA  Federation Contract Negotiation & Audit 3. CARSI FPR  Federation Provider Registry 4. CARSI OpenIdP  An IdP providing free registered fed account for test users 5. CARSI Services  SP-protected web applications for fed users 6. Others

6. 1. CARSI infrastructure CARSI-Fed: cross-domain federation CARSI-portal  A web portal for fed user login  A web portal providing resource list for fed users CARSI-WAYF: where are you from CARSI-VRD: Virtual Resource Directory CARSI-Person: CARSI User Attribute Specification  CARSI-Uid(Universal user identity): localid@domainid CARSI-IdP: shibboleth IdP + CARSI-SP: shibboleth SP +

7. Infrastructure Workflow Way 1: 1. Portal login -> 2. select application from resource list -> 3. visit web application Way 2: 1. request to visit web application -> 2. redirected to portal to login -> 3. visit application

8. CARSI-Portal

9. Infrastructure Workflow Way 1 Demo Web browser CARSI IdP CARSI SP Application CARSI WAYF CARSI VRD CARSI Portal CARSI SP

10. Web browser CARSI IdP CARSI SP 1. login with CARSI-Uid Application Infrastructure Workflow Way 1 Demo CARSI WAYF CARSI VRD CARSI Portal CARSI SP

11. Web browser CARSI IdP CARSI SP 2. Redirect to IdP 3.Pass auth, redirect to VRD 4. Resource list returned to user Application Infrastructure Workflow Way 1 Demo CARSI WAYF CARSI VRD CARSI Portal CARSI SP

12. Web browser CARSI IdP CARSI SP 5. Select an application to visit 6. Visit SP-protected application 7. First time visit the resource, redirect to WAYF 8. Redirect to visiting user’s IdP 9. The user has passwd auth, redirect to SP Application Infrastructure Workflow Way 1 Demo CARSI WAYF CARSI VRD CARSI Portal CARSI SP

13. Web browser CARSI IdP CARSI SP CARSI WAYF CARSI VRD CARSI Portal CARSI SP Application 10. Pass authorization, user accesses application Infrastructure Workflow Way 1 Demo

14. 2. CARSI FCNA Federation Contract Negotiation & Audit Goal:  How many and what kind of influences does cross-domain AAI bring to users(IdP) and applications(SP)?  How can cross-domain AAI running in a controllable way? Contract? Negotiation? The economic model?  How is cross-domain AAI being used? What’s user’s using habit? Methods:  Federation log record, aggregation and analysis: IdP log, SP log, Portal log, WAYF log, etc.  Resource sharing statistics Based on IdP, how many IdP users visit other-domain applications, their using habit, etc Based on SP, which domain and what kind of users visit it, what is the peak visiting time, etc  User’s behavior and action tracking Tracing user’s visiting sequence Which visiting sequence is more adopted? How cross-domain AAI benefit them?

15. CARSI FCNA interfaces

16. 3. CARSI FPR: Federation Provider Registry A system for federation members to manage domain/IdP/SP by themselves Administrators are required to register accounts depending on administrative object Administrator account management is role-based  Role: FedAdmin, OrgAdmin, IdPAdmin, SPAdmin IdP/SP register and management  Followed with corresponding management policy IdP/SP/Admin policy

17. 3. CARSI FPR: Federation Provider Registry FedAdmin  To manage member administrator accounts and member IdP/SPs OrgAdmin  To manage Admins of a domain/organization  Activated by paper documents stamped with organization seal  1 domain may have multiple admins with OrgAdmin role IdPAdmin  To manage 1 IdP  Activated by OrgAdmin or other IdPAdmin for the same IdP  1 IdP may have multiple admins with IdPAdmin role SPAdmin  To manage 1/n SPs  Activated by OrgAdmin or other SPAdmin for the same SP  1 SP may have multiple admins with SPAdmin role

18. 4. CARSI VRD: Virtual Resource Directory A list of sharing web applications One part of CARSI-Portal Synchronized with FPR-registered SPs SP protected Classified and exhibited for user access

19. 5. CARSI-OpenIdP An open identity provider Freely registered Mainly for test purpose

20. 6. CARSI-Services Online served: Black Board System PKU Exquisite Courses Campus IP gateway Content Management System Network Management Systems On-going: CARSI vConf: Video Conference CARSI library others

21. Current Deployment Members:  5 of 10 CERNET regional nodes: Peking Univ., Tsinghua Univ., BUPT, SCUT, UESTC  1 research institute: Research Institute of Telecommunication Transmission Applications: about 10

22. Current Deployment

23. Current Focuses: Complete the above key functions Extend the federation to more universities. Attract more applications. Find out an easy way to make applications shibbolethed

24. Thank You! CARSI: http://www.carsi.edu.cn Email:carsi@pku.edu.cn