You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This page is being used to collect potential use cases related to a centrally manged Social-to-SAML Gateway. They will be discussed on the May 21, 2012 socialidentity working group conference call.

  1. Jane Doe invites John Smith (a member of the local community) to participate in her course for two weeks as an adjunct instructor. She goes to the campus instance of MACE Grouper and sends to John's personal Google account an invitation to become a member of the INSTRUCTORS group for her course. John receives the email, and clicks on the enclosed url. This takes John back to the campus instance of MACE Grouper, and he is asked to identify his Identity Provider; he selects Google. This takes him to the centrally managed Social-to-SAML Gateway, and on to Google. He authenticates at Google, approves releasing attributes, is returned transparently to the Social-to-SAML Gateway, which forwards him back to the campus instance of MACE Grouper, which now recognizes him as an authenticated user. John clicks ACCEPT, and is added as a member of the INSTRUCTORS group.
  2. Emily Doe invites Bucky Doe (her dad) to view her billing and grade information.  This information is stored in PeopleSoft.  She goes to the provided interface from which she provides her father's email address.  Bucky is sent an email and clicks on the enclosed URL.  This takes Bucky to a specialized PS page where he selects his Identity Provider (or some language more user friendly), and he selects Google. This takes him to the centrally managed Social-to-SAML Gateway, and on to Google. He authenticates at Google, approves releasing attributes, is returned transparently to the Social-to-SAML Gateway, which forwards him back to the campus PS service, which now recognizes him as an authenticated user.
  3. Chuck U. Farley has accepted a postion with the University.  Before his hiring can be completed, he must log into the campus PeopleSoft instance and complete information that will be used in a criminal background check.  Prior to accessing this workflow, he is directed to an interface where he provides his email address and identifies which Identity Provider this email address is associated with.  After completing this form, Chuck is sent an email and clicks on the enclosed URL.  This takes Chuck to a specialized PS page where he selects his Identity Provider (or some language more user friendly), and he selects Google. This takes him to the centrally managed Social-to-SAML Gateway, and on to Google. He authenticates at Google, approves releasing attributes, is returned transparently to the Social-to-SAML Gateway, which forwards him back to the campus PS service, which now recognizes him as an authenticated user.
  4. Systema D'Min manages the Visiting Committee Portal of which Don Or, a very influential person in the community, is a member of the committee. Systema needs to enable Don to access the private areas of the portal, and due to various reasons Don doesn't want to be bothered with yet another account and password. Systema, knowing Don's Google address, enters it into the local ACL for the portal and requests that Don login. Don follows the link, at the portal selects Google, is sent transparently through the central gateway to Google, authNs & consents, and is sent back to the portal.
  • No labels