On July 15, 2011 4:12 , "Bennett, Steve" <[email protected]> wrote: > I solved the problem by intercepting the browser redirection between > authentication and validation. I altered the cosign configuration so > that the validation URL for a service was changed from something like: > https://webapp.domain.edu/cosign/valid > to something like: > https://messageapp.domain.edu?https://webapp.domain.edu/cosign/valid > The service at messageapp.domain.edu (itself a cosign webapp) looks at > the users identity and decides what messages to display, and eventually > forwards the browser on to the "real" webapp.
I like this solution a lot -- it is easier to set up and less intrusive than the one I suggested. The only advantage to involving factors (that I can think of) is that it puts control of whether or not to display a form or a message in the hands of the person administering the cosign-protected service: the factor can be required (or not) on a per-service or even per-page basis; but hopefully most institutions would not need this sort of granular control, and so I think your solution is definitely the better one. -- Mark Montague [email protected] ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
