LionShare: A Hybrid Secure Network for Academic Collaboration. Michael J. Halm, Marek Hatala, Derek Morr and Alex Valentine

Transcription

1 LionShare: A Hybrid Secure Network for Academic Collaboration Michael J. Halm, Marek Hatala, Derek Morr and Alex Valentine

2 Presentation Overview Brief LionShare Overview LionShare Security Overview Connecting LionShare and Repositories Short LionShare Demo September 21,

3 LionShare Overview Michael J. Halm - Project Director

4 Problems Identified Proliferation of digital resources Tools to manage personal collections Difficulty finding appropriate resources Difficulty merging public/private collections Need for faculty/student/dept s to manage large collections Need for copyright and access control September 21,

5 What is LionShare? Secure, P2P file sharing network for academic collaboration Major features Digital Identity based on existing campus infrastructure Federated Search of P2P and academic repositories Share files locally or on the network Collaboration services included September 21,

6 LionShare Features Authentication and Authorization Directory Integration (LDAP) Verification of Sharer s Identity Access Control Network File Storage and Sharing Automated Metadata Image Preview Federated Repository Search User Profile Support for Multiple Metadata Schemas Creative Commons Licensing September 21,

7 Basic LionShare Components September 21,

8 LionShare Trust Fabric September 21,

9 Federated Repositories September 21,

10 LionShare Security Overview Derek Morr - Security Developer

11 LionShare Criteria Can t share files anonymously Can optionally share with ACLs Searches are anonymous Retrieval is pseudonymous We can t mandate authn mechanisms Reuse existing infrastructure

12 File Sharing modes Plain mode: Must authenticate to share files Can query for and retrieve files anonymously Files sent in the clear Protected mode Must authenticate to share files Can query for files anonymously Must authenticate and retrieve attributes to get file Files encrypted during transmission September 21,

13 LionShare Solution X509 for authn - SASL-CA Like the U. Michigan kca, but more flexible SAML for attributes Using a plugin to Shibboleth 1.3 XACML for authz

14 Why the SASL-CA? We wanted a PKI without requiring one. Short-lived certificates; 8-10 hrs Single-use certificates Certificates are never stored Needed identity and opaque certs Couldn t be tied to just Kerberos Needed flexible attribute sources

15 Certificate Contents Identity certificate: Has a regular DN Used to share files on a network Ex: CN=DEREK VAUGHAN MORR(dvm105@psu.edu)/dvm105@psu.edu, OU=ACADEMIC SERV & EMERGING TECH, O=Pennsylvania State University, L=UNIVERSITY PARK, ST=Pennsylvania, C=US

16 Certificate Contents Opaque certificate: Has an opaque DN (a Shibboleth handle) Used to request files from other peers and obtain attributes Ex: CN=AGOCMHOJJN2TJUYVV672M672UBW7FQ2OXGKX RCOTHPQ7TQDUPGUEKPGNVDWJBBNFC2T3RLVVCMTJFXW 6BIDBM6LLYNSCUNZITWHRGZY

17 LionShare Security Model

18 Queries Either use standard Gnutella filenamebased query or a metadata-based search. Queries are unsigned, unencrypted and unauthenticated. This was chosen for scaling issues. Any user can query for any file.

19 QueryHits Cryptographic hash of the file Traditional metadata stream IEEE-LOM, Dublin Core, etc (Optional) list of required attributes Digital signature of the metadata Signed with server peer s identity cert.

20 Metadata & Signatures The signed metadata is persisted. The certs and keys are not. We don t resign metadata unless it s changed. We allow expired signatures, but only on file metadata. Protocol messages always include a signature from a valid cert.

21 Attributes Users decide, at run-time, which attributes to release to whom. Individual peers query the AA to obtain a signed attribute assertion. Attributes must be created with Holder-of- Key confirmation using the client peer s opaque cert.

22 File Retrieval

23 LionShare Trust Fabric

24 Technical Requirements Authentication System Directory Service (edupersonenabled) Shibboleth Identity Provider SASL-CA Federation membership

25 Connecting LionShare and Repositories Marek Hatala - ECL Architect

26 What is ECL? ECL Network is an infrastructure connecting (learning object) repositories and other networks where objects are (typically) described by metadata ECL: EduSource Communication Layer September 21,

27 Design Considerations Heterogeneous network of repositories and tools Evolves over time End-user selection of services Pre-configured middleware to support adoption Design for crosswalks between ECL and other systems September 21,

28 ECL Network September 21,

29 edusource Communication Layer IMS Digital Repository Interoperability (IMS DRI) core functions: Search/Expose, Gather/Expose, Request/Deliver, Submit/Store, Subscribe/Alert ECL Protocol implements IMS DRI web services ECL Infrastructure supports openness and discoverability September 21,

30 Security Design Repositories have different needs for security and privacy Free access Repository managed accounts Federated security Example: SFU Surrey CMS Free material Library material (academic community) Licensed material from publishers (course only) Goal: Provide as broad access as possible September 21,

31 ECL Infrastructure with Security September 21,

32 ECL Message with SAML Attributes September 21,

33 ECL Search Query Example Support Xquery Interoperable Advanced Query Structure for All Type of Databases September 21,

34 ECL Message with Encryption (Body) September 21,

35 Connecting ECL and LS Network Two goals: Secure access for LS users to repositories LS client *is* ECL Client, They share all security credentials and infrastructure Secure access for ECL users to LS network (as a whole) ECL/LS gateway New 3-tier attribute-based access September 21,

36 Federation Authenticate Authenticate SFU CAS Retrieve Attributes PSU Kerberos Retrieve Attributes Local LDAP Local LDAP SFU Shibbolet Identity Provider PSU Shibbolet Identity Provider Federation ECL Upload Shared Resources Simon Fraser Surrey University LionShare Peer-to- Peer Community SFU Learning Object Repository LionShare PeerServer September 21,

37 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

38 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 0. ECL Client received QUERYHIT from the LS peer from the ELC/LS gateway and wants to download the resource ECL Client 1: SSL authenticate / Retrieve authentication assertion 5: ECL Request with Authentication Assertion 6: Make SSL attribute query With Signed SAMLQuery LS Gateway 7: Validate GW certificate From SAMLQuery 9: Download resource with Attribute Assertion SP metadata PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

39 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP ECL Client 1: SSL authenticate / Retrieve authentication assertion 5: ECL Request with Authentication Assertion 10: Return resource 6: Make SSL attribute query With Signed SAMLQuery LS Gateway 7: Validate GW certificate From SAMLQuery 1. ECL Client open SSL connection to WS endpoint on Shib IdP and requests Authentication Statement with HoK element 9: Download set to the resource with ECL Client. The audience is Attribute restricted to GW Assertion and IdP. SP metadata PSU LAA 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

40 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery 2. The IdP authenticates the user against CAS. SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

41 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP ECL Client 1: SSL authenticate / Retrieve authentication assertion 5: ECL Request with Authentication Assertion 10: Return resource 6: Make SSL attribute query With Signed SAMLQuery LS Gateway 7: Validate GW certificate From SAMLQuery 3. The IdP verifies that the user has a record with the directory services. 9: Download resource with Attribute Assertion SP metadata PSU LAA 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

42 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery 1R. The IdP returns the Authentication Statement. SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

43 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP ECL Client 1: SSL authenticate / Retrieve authentication assertion 5: ECL Request with Authentication Assertion 10: Return resource 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery 4. If user approves the release of the attributes. This step is required only if the release of the attributes not covered by the default release policy in Idp is requested. If the 9: Download user does not allow the resource with release of the attributes Attribute the Assertion processing stops at this LS Gateway point. SP metadata PSU LAA 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

44 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 5. The ECL Client sends ECL Request to the GW with Authentication Statement via the HoK method. The ECL message is secured via WS SAML profile (WSS4J) 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

45 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 6. The GW sends request to IdP with Authentication Statement, list of requested attributes (or null), and SASL-CA certificate to be placed as the HoK element to the Attribute Assertion. 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

46 3-tier Attribute Based Access SFU CAS 2: Authenticate User 7. The IdP validates that the request was sent from trusted GW that has the right to request attributes for the user (as all trusted SP do). 1: SSL authenticate / Retrieve authentication assertion SFU Shib IdP' 6: Make SSL attribute query With Signed SAMLQuery 3: Verify 8: Retrieve attributes 7: Validate GW certificate From SAMLQuery SP metadata SFU LDAP ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

47 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 8. The IdP retrieves the attributes. If the list of the attributes is null, the IdP releases the attributes according to the default policy, otherwise the ARP engine is bypassed. 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

48 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 6R. The IdP returns the Attribute Assertion with HoK element set to GW SASL-CA certificate. The Audience Restriction Condition is empty. 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

49 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 9. The GW opens SSL connection to LS client with HoK method. It passes the Attribute Assertion to the LS client and downloads the file. 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

50 3-tier Attribute Based Access SFU CAS 2: Authenticate User SFU Shib IdP' 3: Verify 8: Retrieve attributes SFU LDAP 10. The GW returns the resource as a secured response to the ECL Request. The resource can be returned in multiple chunks. 1: SSL authenticate / Retrieve authentication assertion 6: Make SSL attribute query With Signed SAMLQuery 7: Validate GW certificate From SAMLQuery SP metadata ECL Client 5: ECL Request with Authentication Assertion LS Gateway 9: Download resource with Attribute Assertion PSU LAA 10: Return resource 4: User approves release of the attributes LionShare PeerServer LionShare Peer-to- Peer Community September 21,

51 Conclusion LS client connects to repositories via web services with security layer (Secure ECL) ECL users connect to LS Network via ECL/LS gateway that connects to a particular segment of LS network September 21,

52 LionShare Demonstration Alex Valentine - Lead Developer