On 8/3/12 3:48 AM, "jleleu" <lel...@gmail.com> wrote:
>Things are getting clearer now and I will start writing the spec next >week. > >I think we could do better than just working "in the right direction", so >I also plan to create a roadmap with several iterations, each iteration >with several tasks to do. This way, everyone who wants to contribute can >pick up a task and help. The spec and roadmap will be of course >proposals, to be discussed and validated. Great! >Nathan, I have three questions for you : > >1) Server enforcement (proactive) >It's not clear to me how increasing LOA is triggered in this case. This is actually mostly outside of the scope of CAS, though I think CAS should have extension points to handle this, and maybe a delivered example implementation. Our biggest use-case is with password policies and password strength requirements. Let's say we have a conference attendee who can only access the conference registration tool. Let's say he is required to have a password of 6 characters or more. At a later date he is hired as an employee. This triggers a rule such that he must now adhere to a different password policy, such as 8+ characters with mixed case and special characters. We intend to implement all of this outside of CAS using SOA, Drools, Grouper, and LDAP. Data flows from our HR system through our SOA, triggering Drools to run, which computes role membership and stores that into Grouper, which then assigns group membership in LDAP. This is related to CAS in two ways: 1) We want CAS to include a password strength indicator as part of authentication metadata associated with an LDAP user/pass authentication event. 2) We want CAS to run some code that compares current password strength against required password strength (based on LDAP group membership) during login, with the ability to intercept the login and force the user to enter a new password before continuing. This fits directly with the concept of "interrupt screens" previously discussed in a different thread (generally in the context of acceptable use polices). I feel that interrupt screens make up an important aspect of a complete LOA implementation. I think there should be a pluggable spot in CAS to handle interrupt screens, and that we should provide a default (example) implementation for password strength requrements. >2) Numeric value of the LOA >I think it will lead us to complex algorithms to have LOA with range >level (2 - 4) instead of many LOA, each having only one value. >Any concern with that ? Yes, complexity is a concern. I actually would probably implement that with multiple LOA policy definitions (as you recommend), like this: (auth_method = LDAP) and (password_strength < 5) ==> LOA=2 (auth_method = LDAP) and (password_strength >= 5) and (password_strength < 8) ==> LOA=3 (auth_method = LDAP) and (password_strength >= 8) ==> LOA=4 The point is that there is a mapping from the authentication methods _and their attriutes_ to LOA numbers. And the mapping needs to be reversible, so that if a user happens to violate a numerical policy, then the CAS server can given them adequate instructions about what to do next or at least why they were rejected. >3) About LOA requested by clients, you described very ambitious >scenarios, like "LDAP username/password with a password strength of 8 or >more, Google Authenticator, or a TGT session cookie that was established >using one of the other accepted methods and used within the past four >hours". >I would simplify that by saying that you can request a LOA with a >specific numeric level (3 = medium security, for example), which can >match several LOA or you can request a specific LOA (authenticate with >Google). >I assume that LOA requested by clients are always known on CAS server >side. >Does it match your use cases ? My original assumption was that the server would contain a set of authentication methods (each identified by a unique string, such as "ldap" or "Facebook") and a set of expressions (policies) that map combinations of these methods and their metadata to numeric values. When all is said and done, the client needs to somehow specify which policy they want to use. You could, for example, include a string with the policy's expression right in the query parameter when redirecting from client to server. You could also pass a numeric identifier that could be mapped to one or more server-side policies. Alternatively, you could pass a policy string identifier or list of acceptable identifiers (instead of a number) that correspond to policies pre-registered with the server. Finally, you could store a specific policy expression, number, or list of acceptable identifiers as an attribute of the registered service if you're using the Service Registry. I think it would be sufficient and cover all of my use cases to require policy expressions to be pre-registered in some way on the server and only use a number or a list of string identifiers to communicate policy requirements from client to server. -Nathan -- 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
