IMPACT RESEARCH INVESTMENT DISCOVERY OPPORTUNITIES STRENGTHS ACCESS RESOURCES EFFICIENCIES COLLABORATION

Transcription

1 University of Chicago University of Illinois Indiana University University of Iowa University of Maryland University of Michigan Michigan State University University of Minnesota University of Nebraska-Lincoln Northwestern University Ohio State University Pennsylvania State University Purdue University Rutgers University University of Wisconsin-Madison IMPACT RESEARCH INVESTMENT DISCOVERY OPPORTUNITIES STRENGTHS ACCESS RESOURCES EFFICIENCIES COLLABORATION

2 Cooking in the Cloud: Planning for Cloud Service Integra7on Kevin Morooney, Pennsylvania State University Keith Wessel, University of Illinois at Urbana- Champaign

3 Challenges Hint: Integra7on is not first on the list Contract language (FERPA, HIPAA, intellectual property) Billing and price aggrega7on across distributed units THEN integra7on. Don't tell me it's complicated to do it right. Tell me how to get started quickly and simply, even if we don't get all the bells and whistles. 3

4 What is the Cloud Service Cookbook? Best prac7ces and recommenda7ons for implemen7ng federated services for campuses and cloud service operators Recipes that save resources: it s important to eat, but if you mix hot pepper, chocolate, vinegar and mustard, the result won t be worth ea7ng, and the en7re product will need to be thrown out Well- developed and tested recipes from some of the most experienced kitchens 4

5 Why a Cloud Service Cookbook? Oranges and garlic Vendors might not tell you everything you need to do; they might not even know. The cookbook will point out things that the vendor doesn t. Frozen pizza It's easy to cut corners when it means more cost to someone else. 5

6 Four Stages of Cloud Service Adop7on Denial, anger, bargaining, and acceptance? Awareness Economics Smart shopping Smart integra7on 6

7 Topics in the cookbook Determining who our users are and what they re allowed to do Working within the federa7on Sharing the burden User experience Policy and Compliance Addi7onal Content Higher Ed. IdM Landscape Case Studies Sample RFP language 7

8 Case Study: What s in a username? Illinois had an exis7ng partnership with a cloud service for student assessments. In moving from vendor s built- in authen7ca7on to Shibboleth, wanted us to re- define an exis7ng aaribute to match exis7ng usernames. Vendor, once they understood the situa7on, was easily able to transform their locally stored usernames. Advice: don t re- define an aaribute for use by a single vendor, and don't just take the first "no" as a final answer. 8

9 Case Study: The Customer is Always Right OSU star7ng to take a harder line on InCommon membership and usage for vendors. Vendor on a recent project signed the membership agreement faster than the sponsoring e- mail was sent. Effort to support services that register metadata and support dynamic provisioning with InCommon is dras7cally reduced. Advice: force vendors to do the right thing and we all benefit. 9

10 Conclusion Cookbook drag: haps://carmenwiki.osu.edu/x/nldcag Vendor Guide:haps://carmenwiki.osu.edu/x/uYPcAg Please share with your technical staff and project managers. Kevin Morooney, Keith Wessel, 10

11 11

12 What's Driving Us Into The Cloud? Hint: it's not (mostly) about saving money Speed of innova7on Responding to elas7city of demand Taking advantage of scale - geographic redundancy, backups, etc. 12

13 Challenges Hint: Integra7on is not first on the list Contract language (FERPA, HIPAA, intellectual property) Billing and price aggrega7on across distributed units THEN integra7on. Don't tell me it's complicated to do it right. Tell me how to get started quickly and simply, even if we don't get all the bells and whistles. 13

14 Differences from Local Deployment Provisioning / Deprovisioning Policy Alignment User Support Loss of control: both financially and technically Vendor models cater to corporate/enterprise norms, not university technical models 14

15 What is the CIC? Commiaee on Ins7tu7onal Coopera7on Collabora7ve effort between the Big Ten schools and the University of Chicago The CIC s size, technical breadth, and collabora7ve environment gives broad input and insight to this project. In the CIC, even a small federated service can be used by hundreds or thousands of users. Increased scale makes following best prac7ces even more important. 15

16 What is the Cloud Service Cookbook? Best prac7ces and recommenda7ons for implemen7ng federated services for campuses and cloud service operators Recipes that save resources: it s important to eat, but if you mix hot pepper, chocolate, vinegar and mustard, the result won t be worth ea7ng, and the en7re product will need to be thrown out Well- developed and tested recipes from some of the most experienced kitchens 16

17 Why a Cloud Service Cookbook? Oranges and garlic Vendors might not tell you everything you need to do; they might not even know. The cookbook will point out things that the vendor doesn t. Frozen pizza It's easy to cut corners when it means more cost to someone else. 17

18 Four Stages of Cloud Service Adop7on Denial, anger, bargaining, and acceptance? Awareness Economics Smart shopping Smart integra7on 18

19 Awareness We don t need to sell you on the benefits of cloud services. They clearly can save resources if the process is done right from the start. Be aware: Know your needs and your internal systems and processes. Not knowing enough might get you pigeon- holed into something that causes more harm than good. 19

20 Economics If done right, integra7on with an exis7ng system can be far faster than building your own. Doing it right involves having your own ducks in a row and using a vendor who follows standards and best prac7ces. 20

21 Smart Shopping There may be many op7ons in the cloud. Knowing the right things to ask can speed up integra7on, ease user support, and save money. Internet2 s Net+ offerings might serve as good guidance, but there are also many op7ons to consider outside of Net+. Understand what you need out of a service rather than lerng the service s capabili7es determine what you can get. 21

22 Smart Integra7on Start with the end in mind. Create policies, a provisioning and deprovisioning strategy, and plans for authen7ca7on/ authoriza7on before doing anything else. 22

23 Case Study: What s in a username? Illinois had an exis7ng partnership with a cloud service for student assessments. In moving from vendor s built- in authen7ca7on to Shibboleth, wanted us to re- define an exis7ng aaribute to match exis7ng usernames. Vendor, once they understood the situa7on, was easily able to transform their locally stored usernames. Advice: don t re- define an aaribute for use by a single vendor, and don't just take the first "no" as a final answer. 23

24 Case Study: The Customer is Always Right OSU star7ng to take a harder line on InCommon membership and usage for vendors. Vendor on a recent project signed the membership agreement faster than the sponsoring e- mail was sent. Effort to support services that register metadata and support dynamic provisioning with InCommon is dras7cally reduced. Advice: force vendors to do the right thing and we all benefit. 24

25 Technical Pointer: Aaribute Release For those opera7ng or planning to operate an InCommon IdP, consider a more relaxed aaribute release policy. Providing standard aaributes such as name and affilia7on to trusted services avoids per- service nego7a7on and expands the value of your IdP. Consider the InCommon Research & Scholarship Category as an entry point. 25

26 Technical Pointer: Join a Federa7on Leveraging trust models, metadata aggregates, and opera7onal agreements can save 7me and money. It s easier to trust when everyone s on the same page for good opera7ng prac7ces. Federa7on based on metadata distribu7on eases on- boarding services and revoca7on of compromised keys. 26

27 Conclusion Cookbook drag: haps://carmenwiki.osu.edu/x/nldcag Vendor Guide:haps://carmenwiki.osu.edu/x/uYPcAg Please share with your technical staff and project managers. Kevin Morooney, Keith Wessel, 27