I've got some use cases that I wanted to share. The most urgent need originally was to add some type of mfa support to CAS or Shib. Initially I built a custom integration between duo and CAS. However Shib has OOB integration with duo now. Also some companies have extended this integration even further to do some really cool stuff which prompted this email. I've read the CAS LOA spec and use cases and I think they are a great starting point. Here are some additional things to consider:
1) user has authenticated to vpn protected by user+pass+duo. user accesses app in browser which has a 2-factor requirement. After logging in with user+pass, he is not sent to duo prompt screen for additional interaction(push,OTP) because he has already done so via vpn. Maybe the new silentcredentialsgatherer could be used which does an IP check for a particular IP range. 2) user mfa preferences: In addition to storing app preferences(auth handlers required for each service), CAS should also store user preferences in a db. Use case: mail app doesn't require mfa but user wants to do so anyway. I realize this one might seem large considering the small benefit you get from it however some institutions are already doing it with shib. 3) user/service pre-auth: app requires different security strengths for different groups of people. In some cases, apps might have a separate url pattern for their admin module. For example, appxyz.com/admin could be in the service registry as requiring mfa wheres the appxyz.com entry would use the normal auth handler. Now some apps can't be protected like that because the url doesn't indicate the level of security required. For these apps, security level should be based on users/groups/roles. One way to do that would be to store a ldap filter regex with each service in the registry. Example: mycoolapp.com secfilter: "edupersonaffiliation:professor.*" : <assurance policy line reference that corresponds to a level of 40> secdefaultauth: <assurance policy line reference that corresponds to a level of 20> Or maybe the filters could be defined at the custom assurance policy line level if that would be cleaner. Now you are thinking: on the login page we don't have the username before we know what type of credentials to ask the user for. Here are a couple possibilities: 1) Only prompt for the username on the first screen. Then after the user clicks next, the logic runs that determines which auth handlers should be used and thus what the next screen should be. OR 2) Dynamic ajaxy stuff: After entering username and hitting tab or clicking on the password field, the logic runs (querying ldap etc) to determine what if any additional fields should be added to the display (duo OTP prompt for example). I look forward to your thoughts. -Dan -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
