As many of you know, we've been conducting calls on adding multi-factor authentication support to CAS. We're looking to now expand the collaboration to the mailing list. So this will be a first in a series of threads about multi-factor authentication.
One of the items were working on how is how to represent to the failure to satisfy the MFA requirements to the user. We currently send back the following information when there is a failure to obtain a ticket: https://source.jasig.org/cas3/trunk/cas-server-api/src/main/java/org/jasig/cas/server/login/ServiceAccessResponse.java (via extension: https://source.jasig.org/cas3/trunk/cas-server-api/src/main/java/org/jasig/cas/server/login/LoginResponse.java ) Essentially its all of the authentication reasons a request might fail. There are some exceptions for when sessions are invalid, or a ticket can't be created (i.e. the protocol isn't recognized). We now need to represent MFA failures. There appear to be a few options: * Throw an exception (but then what would the payload of this exception be?) * Return the name of the policy that failed to be satisfied (and delegate the request for additional information to the policy?) * Return what needs to be done to satisfy the policy (this could mean the list of credentials that could satisfy the requirement) One concern is that policies could get too complicated to represent well via this return method. Though for complex polices, this would just move the complexity to the policy interface. Anyone have any other ideas on ways to represent this information? Anyone done something similar? We're trying to get these APIs stable for 3.5 even if complete MFA support isn't in 3.5 (we're looking to do this since 3.5 is already introducing major API changes). The alternative is to design the APIs organically (i.e. we know how to deal with multiple credentials and we know how to deal with it and we have support so implement that now and just change the other APIs later). The alternative may be okay because while its a major API most people will use our presentation logic that calls it as well as our default implementation. Cheers, Scott -- 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
