|
cosign-discuss at umich.edu
|
general discussion of cosign development and deployment
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cosign Re-Authentication Specification
> 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
|