Exploring Cloud Credentials for Institutional Use
•Télécharger en tant que PPTX, PDF•
0 j'aime•455 vues
Presentation on the use of Social Credentials to access institutional resources.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Exploring Cloud Credentials for Institutional Use
Similaire à Exploring Cloud Credentials for Institutional Use (20)
Plus de Jeremy Rosenberg
Dernier
Dernier (20)
Exploring Cloud Credentials for Institutional Use
- 1. Exploring Cloud Credential Use Logging in with Facebook or Google Accounts
- 2. • What is CAS? • Authentication vs Authorization • What is OAuth? • How do programmers use OAuth? • How does CAS work with OAuth? • Use Cases • What about security? • Workflow Comparison Overview SFU CAS 2013 2
- 3. • Central Authentication Service • Centralized • One Username for all SFU systems • Convenient • No need to enter password again • Trusted • Password never leaves CAS What is CAS? SFU CAS 2013 3
- 4. SFU User Log In Flow SFU CAS 2013 4
- 5. • Authentication • Verify who you are • Username + password = Authenticated • Authorization • What you are allowed to do/see • Authentication + Role/Group = Authorization • CAS primarily handles Authentication Authentication vs Authorization SFU CAS 2013 5
- 6. • Authentication • A key to a building • But all the offices are locked • Authorization • The key for any given office • Handed out by the office managers Authentication vs Authorization as Access Control SFU CAS 2013 6
- 7. • OAuth is a standard for asking permission • Google and Facebook use OAuth to let other services ask for permission to access their user’s information • Any programmer can use OAuth to provide access to their applications via Google or Facebook credentials • But it’s complicated and there is potential to get it wrong What is Oauth? SFU CAS 2013 7
- 8. How do programmers use OAuth? SFU CAS 2013 8
- 9. • It’s complicated, but SFU has use cases – Guest Lecturers in Canvas – Protected shared collaboration spaces with non-SFU researchers – Non-SFU email addresses in Maillist – Continuing Studies students with limited access requirements – Anonymous web surveys without duplicate answers • Anytime the “office manager” would like to provide access to people who can’t get into the “building” Potential SFU Use Cases? SFU CAS 2013 9
- 10. • Applications must Opt-In, OAuth is off by default • SFU Applications already use CAS • CAS handles all the complicated communication on the application’s behalf • Ensures best practices • ONLY handles Authentication • Authorization is still handled by the Application How does CAS work with OAuth? SFU CAS 2013 10
- 11. Non - SFU User Log In Flow SFU CAS 2013 11
- 12. • Authentication without Authorization does not provide access to anything • Authorization remains the domain of the application • Currently SFU issues thousands of “sponsored” accounts which is a security concern itself – Encourages shared accounts – Overloads the system – Encourages credential reuse – No accountability What about security? SFU CAS 2013 12
- 13. Current Workflow Proposed Workflow 1. Instructor directs Guest to an office administrator for a sponsored account 1. Guest lecturer provides instructor with Google or Facebook username 2. Office administrator contacts IT Services to secure a guest account 2. Instructor adds lecturer’s Google or Facebook username to Canvas course 3. Guest account is issued and password is communicated to office administrator 3. Guest lecturer logs in to Canvas, via CAS, with his Google or Facebook username 4. Office administrator communicates username and password to lecturer and username to instructor 4. Instructor removes Guest lecturer’s account from Canvas after the lesson is complete 5. Instructor adds lecturer’s account name to Canvas course 6. Lecturer logs in to Canvas with provided username and password (hopefully remembering the auto generated password he received from the office administrator) 7. Instructor removes Guest lecturer’s account from Canvas after the lesson is complete 8. Guest account remains active until expiry date Workflow Comparison Guest Lecturer needs access to Canvas for one lesson SFU CAS 2013 13
- 14. • This will not allow outside applications to access SFU user information • SFU developers will need to explicitly apply to the CAS administrators in order to be granted access to this feature • Developers will be trained by CAS staff to ensure appropriate use of this feature • SFU developers will need to make explicit allowances in their application authorization logic to permit external users Review SFU CAS 2013 14
Notes de l'éditeur
- CAS is an open source tool used in hundreds of higher education institutions around the world and managed by the Apereo Foundation. SFU has been running CAS for over 12 years. It is a single sign on tool that keeps the passwords for all account safe while providing verified usernames to applications.
- Simply having a valid username and password combination should not provide access to any system. It should only be taken as verification that the person is who they claim to be. Once their identity has been established via their knowledge of their password, the application needs to take that information and make and authorization decision. This is usually done by checking to see what roles that person has (are they an employee or a student) and of what groups are they members? (Are they members of the class roster for a given course?). Authentication != Authorization, ever. CAS primarily handles Authentication, it is up to the application and the application business owner to then determine who gets access.
- Put another way. Authentication provides access to a building, like having the key to the front door. But every office in the building is locked by it’s own individual lock. So a person with authentication but no authorization can harmlessly wander the halls, maybe use a bathroom or a water fountain. Access to any individual office is granted by the office managers. This analogy can go deeper, often inside a given office there are locked filing cabinets, so even a person with access to the office may not be authorized to access certain files within the office. Authorization of web based applications works the same way. CAS provides a minimum level of access. A person authorized to use Maillist for to manage their own memberships would be allowed into the Mail list office. But in order to access protected administrative functions of Maillist, you would need to be given the keys to admin file cabinet.
- OAuth is a standard created to allow one application to ask for a user’s permission to access that user’s personal information in another system. In this case, the information that an SFU application owner wants, is the user’s Google or Facebook username.
- This is a technical view of the Oauth process meant to demonstrate that it is not a simple process that requires a number of round trips from the consumer to the service provider both through the user to machine and machine to machine.
- A number of application developers are currently waiting for this functionality to be available. Instructors may wish to allow guest lecturers to their courses via the guest’s cloud credentials instead of having to go through the trouble of getting a sponsored account with another password to remember.Research support units have collaborative document repositories that need to be shared with researchers from other institutions, these other researchers could use their cloud credentialsSFU hosts a mail list service that includes many non-SFU email addresses, these non-SFU users could log in to that system and manage their own list memberships for their gmail addressContinuing Studies has many users that require limited access to course resources even though their relationship with the University is measured in hours. This would allow them to get in and out without creating a sponsored computing account.To return to the Building analogy, these are people who an application owner or “office manager” want to allow in to their “office”, but without authentication, those people can’t even get into the “building”
- CAS can greatly simplify and standardize this process. By handling all the communication between the user and the external application, CAS can provide the functionality to the end applications without requiring individual applications to wire up the systems manually and potentially introduce errors and omissions.
- Logging in to CAS only verifies identity. It does not provide any implied access decisions. Applications must currently make access control decisions after a user is logged in. Every person at SFU can log in to connect.sfu.ca to see their email. But they can only see their own email. This is because once the person is authenticated with CAS, SFU Connect makes the access control decision to provide them only with access to their own email and calendars. If a person tried to log in to SFU Connect with their facebook credentials, CAS would communicate with facebook, pass the user’s facebook username through the SFU Connect at which point SFU Connect would inform the user that he or she has no access to SFU Connect. SFU Connect is an example of a service that will not use this feature, since SFU Connect can never be accessed by a person who only has Google or Facebook credentials, the SFU Connect administrators will not opt in to this feature, which means the CAS page that people see when logging in to SFU Connect will not even offer this authentication method.The status quo is actually full of security concerns because it requires us to issue thousands of SFU guest accounts. People tend to share these accounts, there is little to no accountability, it overloads our systems with junk accounts that are no longer used and encourages people to use the same username and password in multiple places which creates a security hazard for us
- This table shows how much simpler and more secure the Oauth powered, proposed workflow would be. Less margin for error, less likelihood of credentials being mistyped or passed in clear text. Steps 3 and 4 are difficult to do securely and are often done via email which is not at all secure. The process becomes completely self serve, does not require intervention by busy office administrators or IT staff and since the username is communicated out of band between the guest lecturer and the instructor, there is sufficient level of assurance for the use case.
- (From slide 6:) We are not talking about allowing outside applications to access SFU’s user information. We are only talking about SFU applications using Oauth to gain access to an anonymous user’s Google or Facebook information under carefully controlled conditions. (From slide 12:) And to make sure that application developers understand that they need to make those access control decisions correctly, CAS must be explicitly permitted, on an application by application level, by the CAS administrators before being able to provide Google or Facebook credential access. (From slide 9) Applications would need to opt in to this service and they would need to make explicit allowances within their application’s authorization logic to permit some access to externally authenticated users.