> renew=true means re-authentication whatever the previous authentication is. > So if you want to stay backward compatible, you can't change this, you need a > renew=increase_loa. > Do you want to specify an explicit loa name by renew or just ask for > increasing loa level ?
I'm glad you're dwelling on this point. I'm wavering on the expected or desirable behavior here, and most of my vacillation is related to the impact on user experience in attempting to satisfy expectations of the service. I would argue that forcing authentication every time the renew parameter is present could represent a fairly unpleasant user experience in some cases. If a user accesses two services with renew=true in succession, I would think most users would be fairly annoyed having to authenticate twice in a short period of time. The security value of this annoyance seems negligible. I'm thinking that perhaps we need to apply some configurable policy to the concept of renew to allow for considerations such as timing as well as security policy that could include LOA. With a policy framework we could presumably allow deployers to choose strict backward compatible behavior for renew, or opt for more control over behavior including assurance considerations. > Can you point me to some docs at "InCommon Assurance program" ? http://www.incommon.org/assurance/ > You're right, there are highest LOA above username/password. By the way, > what's VT ? Sorry, should have said, "Virginia Tech" to be clear. Public university in southwest Virginia where I work. I think it's fair to say we're fairly far along in the use of multifactor/strong authentication to access secure services, so the interest in combining that expertise with SSO is fairly natural growth. > The question is : what authentication mean to display when current LOA is not > sufficient ? So far, we just have one : login page for username/password. > Do we need to create a new concept : authentication mean associated to LOA ? > Or just display the login page when LOA is not sufficient ? This is one of the hardest problems to solve, and in previous discussions on related topics we've punted it as UX problem to be solved later largely due to difficulty and lack of requirements. But with multifactor and identity assurance, the user experience is vitally important since the concepts are fairly sophisticated and users need clear guidance to take required or recommended action to satisfy security requirements. Unfortunately, it's hard to imagine a single framework that would meet the needs of every environment. The only successful approach I can imagine is to solve the problem for a limited number of cases and from that work attempt to generalize. I suppose I didn't answer your question since it's hard to answer in general. I'll offer an answer that's specific to our environment that might be helpful. If the client made an LOA demand of 2, we'd show our user/password UI. If the client made and LOA demand of anything higher, we'd display a custom UI for X.509 certificate authentication. I think it's a reasonable simplifying assumption that for every LOA there would be a distinct UI, so you could model the LOA to corresponding view using a map. I'm fairly certain we'll use this general approach in our solution. On the other hand, I can imagine that some institutions would have various sets of user/pass credentials that have distinct LOA values all served by a single user interface. Those sorts of details make a generalized solution difficult. > So far, we talked about client initiated flows (asking for increasing LOA). > But I think we can also have LOA definition in CAS service (no use of renew > parameter). > Does it make sense to you ? If so, I will add a second example in spec with > LOA defined in CAS service. It absolutely makes sense and sounds like a valuable feature. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
