Hi Thomas, For me, the best solution regarding your design is to add a state in the login webflow. Regarding the client IP address or a parameter in the request, authentication mecanism will be different.
This state should be added just before the startAthenticate/viewLoginForm. Possible transitions should go to startAuthenticate (to launch the spnegoNegociate action) or to viewLoginForm. If you are not able to do it, regarding the client IP address, might customize the login page to add a link "Authenticate me using auto-login" to the login page with an extra parameter. This link should launch the SPNEGO process. Regards, Arnaud Lesueur On Mon, Aug 4, 2008 at 10:24 PM, Healey, Thomas <[EMAIL PROTECTED] > wrote: > All, > > I have a situation here where one set of users can be authenticated via > SPNEGO because they have domain credentials and another set of users who > don't have domain credentials who need to be authenticated and they need to > have access to the same resources. It is not an option to add the non domain > users to the domain. Basically we have alumni (non domain) and students, > faculty and staff (domain users) as the two user groups. Now I can't > implement SPNEGO because when I do it will allow domain users to gain access > to resources without being challenged (as designed) but non domain users > will ALWAYS be prompted with an http auth dialog box which they can fill > out but NEVER SUCCEED in authenticating because they don't have accounts in > the domain. When they fail they are "forwarded" to the CAS login screen > which they then fill out with their credentials and they succeed and then > they can view the resources they were after. The issue is the extra dialog > box that comes up which the non domain user can never succeed in passing and > that is considered to be a poor user experience. I thought of creating a > separate CAS server for the alumni to auth against but then they would get > challenged when they tried to use resources "guarded" by the other CAS > server which would have no ticket for them. So I am stuck. What solutions > are available to me with CAS to allow these two user groups to have optimal > user experiences. That is domain users do not get challenged because they > are already auth'd against the domain previously and non domain users get > challenged once and we do this all within a single CAS server. > > > > Thanks in advance, > > Tom Healey > > Darden School Of Business > > University of Virginia > > > > P.S. if there is a simpler way of explaining what I want I am all for > trying it. > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- Arnaud Lesueur LinkedIn: http://www.linkedin.com/in/lesueur
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
