On 8/14/12 3:48 AM, "jleleu" <[email protected]> wrote:
>Hi, > >Just a single attribute to define the "supported level of assurance" may >seem to be limited, but I had in mind to use the supports method of the >authentication handler to handle password strength issues. >Example : >authentication_handler1 : bind on LDAP, supports method supports only >password length >= 4, LOA = 10 >authentication_handler2 : bind on LDAP, supports method supports only >password length >= 6, LOA = 20 > >Do you think it's sufficient ? In theory I think this would work, but in practice it might not be the best choice. In our environment we'll probably have three password strengths: 1) minimum 6 characters (guests) 2) minimum 8 characters, must include numbers, mixed case, and special characters (standard employees) 3) minimum 12 characters, must include numbers, mixed case, and special characters, changed regularly (employees with expanded access) Now, if we implement this with three separate instances of an LDAP authentication handler, it would likely increase the load on our LDAP server, since if one authentication handler fails to bind, it would fall to the next (and try to bind again), and so on. For good performance and optimization, the three LDAP auth handlers would have to know about and communicate with each other so that they only attempt one search/bind between the three of them. But once you've gone to the effort to do that, you might as well just have one single authentication handler that has the capability of returning more details to contribute to the LOA determination. I think the both code and configuration complexity would be lower that way. I'll write up some suggestions in the wiki to describe a way I think it might work while remaining fairly simple. -Nathan -- 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
