Imagine that there is a company (or household, or department) that has a
wireless access point, firewall, or other network device that also does
NAT, and that there are three users accessing your service from behind
this device. To your server, all three users will appear to be coming
from the same IP address. Without cookies, how will your web server
know what the correct value to "manifest" into REMOTE_USER is?
Note that this problem is not limited to cosign; any authentication
system that relies upon cookies for identification will have the same
problem, including pubcookie, CAS, and others. This is acknowledged in
the SWFUpload manual at http://demo.swfupload.org/Documentation/#plugins
which states, "Some frameworks that automatically check cookies for
session or authentication values still will not be able to find the values."
Possible solutions include:
- Modify SWFUpload to send cookies.
- Modify the 3rd party application to use a different upload system, one
that supports cookies.
- Disable cosign for the URL in question in order to permit anonymous or
non-identity-verified uploads.
Hopefully other people can add better ideas.
P.S.: you are not subscribed to the mailing list, so anything you post
will be held pending moderator approval. Also, you will not see any
replies that are posted to the mailing list (I've manually added in your
email address on this reply so you would see it).
Mark Montague
ITS Enterprise Email& Collaboration Technologies Team
The University of Michigan
[email protected]
On March 25, 2010 08:27 , "J.Lance Wilkinson" <[email protected]>
wrote:
We have a 3rd party application which interacts via a handler with our Apache
server that has the COSIGN Apache Filter being used for authentication.
That application uses the SWFUPLOAD.ORG flash utility to do some of its work.
The flash utility cannot supply the cookies back from the browser's cookie
stash so as a result the input from the flash utility back to Apache and then
that 3rd party application are unauthenticate, and COSIGN's redirect sidelines
the entire operation.
IF there were a way to simply materialize REMOTE_USER (and optionally
REMOTE_REALM) without requiring passing through the COSIGN authenticator yet
again, we'd be able to get around this.
The vendor has no other customers using COSIGN, and has asked if there is some
additional configuration that can be done to have COSIGN simply materialize the
authenticated user in REMOTE_USER for the Flash component. Are there any
other COSIGN users out there that use cosign for authentication and then use
SWFUPLOAD.ORG's flash utility, that may have already customized one or the
other and would be willing to share those customizations?
Is there a cosign directive I'm currently missing that would do this? My
Apache config fragments read like:
476:<VirtualHost *:443>
478: SSLEngine on
479: ServerName servicename.domain.edu
482: CosignHostname cosign.domain.edu
483: CosignRedirect https://cosign.domain.edu/
484: CosignPostErrorRedirect https://cosign.domain.edu/
494: CosignService servicename.domain.edu
502: CosignCrypto /dlt/webservers/cms/certs/author-privkey \
/dlt/webservers/cms/certs/author-pubkey.cer \
/dlt/webservers/cosign/certs/
503: CosignProtected off
504: CosignValidReference ^https?:\/\/.*\.domain\.edu(\/.*)?
505: CosignValidationErrorRedirect \
https://cosign.domain.edu/validation_error.html
506:<Location /cosign/valid>
507: Sethandler cosign
508: CosignProtected off
509: Allow from all
510: Satisfy any
:</Location>
515: DocumentRoot "/dlt/webservers/cms/cms.cache"
516:<Directory /dlt/webservers/cms/cms.cache>
519: AuthType Cosign
520: CosignProtected On
527: SetHandler dispatcher-handler
529: AllowOverride None
530: Options -Indexes -FollowSymLinks
531: Order allow,deny
532: Allow from all
:</Directory>
:</VirtualHost>
Local server's host name sanitized to "servicename.domain.edu".
Local system's COSIGN server name sanitized to "cosign.domain.edu"
Handler for 3rd-party software is "dispatcher-handler"
The 3rd-party software is Day Communiqué, a commercial product based on Apache
Sling and JSR-170. One of the primary authors of JCR-170 is Day's Chief
Scientist, Roy Fielding.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cosign-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
