...

1. Guest -> Student -> Employee
   1. I first interact with CAS when registering for an event as a guest.
      1. For convenience I choose to use Facebook authentication.
   2. A few months later, I join the organization as a student.
      1. Through a process out of the scope of this document, I sign up for a username and password.  These credentials are connected to my existing identity, which up to this point only contained Facebook authentication information.
      2. If I attempt to access a resource intended for guests (app1), I see a login page that does include the Facebook button.
      3. If I attempt to access a resource intended for students (app2), I see a login page that does not include the Facebook authentication option.
      4. Let's say I login to app1 using Facebook, then I navigate to app2.
         
         1. I am presented with the login page again, this time not showing the Facebook button and including a message stating, "You must login with your username and password.  Facebook Connect is not supported for the site you are trying to reach."
         2. After I login, I am taken to the page.
   3. A few years later, I join the organization as an employee.
      1. Through a process out of the scope of this document, I am forced to increase the strength of my password to meet employee standards.  This is likely handled through a business process but also enforced using an interrupt screen in CAS that analyzes my password strength (probably by looking at authentication attributes, the assurance policy, and my organizational roles) and, if necessary, sends me to a self-service change password page after logging in.  The change password page will check my role (in my case by looking in Grouper) and will enforce the employee password policy.
      2. In this case, because password strength has been enforced prior to my accessing a service (through the use of interrupt screens and validation), the service can assume that my password is strong enough.
2. Remember me
   1. I'm a student.
   2. I read a blog on the organization's blog site and I want to leave a comment.  I log in and check the "remember me" box.
   3. When reading another blog a few days later, I am able to leave a comment without logging in again because the "remember me" feature worked for the blog.
   4. I access the event registration web app, and it presents me with the login page because it requires an LOA number higher than that of the "remember me" feature.
3. Trusted external IdP  - Note that this is very similar to using a public IdP like Facebook, and (like Facebook Connect) is basically a form of federation
   1. I'm an employee at a partner organization.
   2. I attempt to access the event registration web app.  On the login page, I click the link "login with username and password from partner organization."  (yes, the real message would be much less generic... more along the lines of "login with facebook" but for the partner org)
   3. I attempt to access an employee portal website, which does not accept employees from partner org.  I am shown the login screen again, with a message saying something like, "You must login with your username and password.  Partner Org login is not supported for the site you are trying to reach."
4. Add a second factor (selected by user) when accessing enterprise app
   1. I access the employee portal and login with my username and password.
   2. I navigate to the organization PeopleSoft HR system.
   3. The system looks up some info in my account and determines that I have my cell phone registered to receive SMS messages and I have Google Authenticator configured.  It presents me with a screen showing the two options and asking me to click one.  I click on the "SMS message" option.  (Note that if I had only previously set up one of these options, the system would have selected it automatically.  If I had not previously set up either option, the system would have given me instructions telling me to set up at least one of these.)
   4. My phone receives a code as an SMS message.  I type this code into a text box on the screen and click "continue".
   5. I am granted access to the PeopleSoft HR system.
5. Extra-strong password policy enforced for user with power-admin role - Note that this is an important LOA scenario, though it is somewhat outside of the scope of LOA in CAS as we're talking about now.  It really highlights how interrupt screens can play an important role in LOA.
1. I'm an employee with access to the PeopleSoft HR system.
2. I'm granted a special role in PeopleSoft that gives me lots of power.  This is registered in the organization's RBAC system (in this case Grouper).
3. The next time I login with my username and password, some code in CAS intercepts my login and realizes that my password is not strong enough for this role.  I get sent to a screen where I must choose a stronger password.
4. After choosing the stronger password, I login again and then am granted access to PeopleSoft.
5. Note that PeopleSoft itself might not specifically immediately request any special password strength (beyond what would be true for all users), since it doesn't know who is accessing it when it redirects the first time.  However, after it has received and validated the ticket, it might take the opportunity to look up the person's assigned roles to ensure that their current password strength or LOA level is sufficient.  In that case it could redirect the user back to CAS with a more specific LOA request.  Alternatively, it would probably block access and notify an administrator, because the interrupt screens should have already done the work to ensure that this aspect of the LOA policy was fulfilled.

...

VII. Roadmap

A) Version 1.0 : only client requested LOA

...