[an error occurred while processing the directive]
![]() |
cosign-discuss at umich.edu |
general discussion of cosign development and deployment | |
> We've been kicking around the idea that a specific Cosign service would > be able to force a re-authentication before allowing a user access to > that service. ... > If the user has already accessed another CosignProtected service ( aka > they ARE logged in ), they will be redirected to the Re-Authentication > Page ( see https://cosign-test.www.umich.edu/reauth.html for a mock-up, This sounds like a good plan. Curious how the filter will be indicating it must be re-authenticated - Ideally I'd want this to be something a particular webserver can dictate without having the weblogin master making changes to the cosign daemon. To do that you either need to have the filter include a new option on the login URL, or have it send something to the cosign server (port 6663) after it determines no cookie is present or valid to indicate the server should require re-authentication. The problem with the first is this: say I sit down at someone else's computer that is logged into cosign, try to get to a re-auth-required page, and it gives me the form. If I remove the '?reauth-requred=1&' section of the URL and resubmit, I have bypassed this restriction. The situation with the second requires the filter to talk to the cosign server even if no cookie is presented to make a new 're-auth' request, but it doesn't know the cosign cookie to ask for re-authentication! So we're back to the first. You'd need to have the first re-auth-required hit set the re-auth-required 'bit' in the cosign cookie on weblogin in the authentication page so reconnecting without the URL field is unsucessfull. Still, a user who visits the weblogin page, impersonating a request without the field data, will still be able to bypass the reauthentication. So perhaps we're back at "server side must be told which services require reauthentication." -- Brian Hatch "I can not have an aide Systems and who will not look up. Security Engineer You will be forever http://www.ifokr.org/bri/ walking into things." Every message PGP signed
Attachment:
signature.asc
Description: Digital signature