Hi Brian, Maybe we used improperly cosign, we wanted to avoid a service architecture being exposed in the centralized configuration of the cosignd daemon, at the same time we wanted to protect all components of the service from unauthenticated access and share realm.
This is a distributed system where the centralized cosignd daemon is delivered with its own rpm while the services are released separately, so we wanted to avoid a contextual update of the two. As said I have separated the service into two services, so this is the right direction, isn't it? Thank you very much for your attention and for quick replying. Letizia Siri Da: Brian Rahn <bdr...@umich.edu> Inviato: martedì 29 giugno 2021 19:20 A: Siri Letizia Angela <letiziaangela.s...@italtel.com> Cc: cosign-discuss@lists.sourceforge.net Oggetto: Re: Cosign cookie question I don't believe there was a direct effort to make the filters incompatible. They were developed separately to meet the same standard. That said, the filters will keep separate cookie caches each requiring their own rechecks through separate connection pools. They are separate services, even if you name them the same. I'm not sure what you gain by mixing them. Brian Rahn On Tue, Jun 29, 2021 at 12:42 PM Siri Letizia Angela <letiziaangela.s...@italtel.com<mailto:letiziaangela.s...@italtel.com>> wrote: Hi, working on project that use cosign, I’ve noticed that cookie time is in milliseconds if created by java filter, while is in seconds if created by mod_cosign.so. Here is an example generated by java filter: cosign-serv1=xWHucaNmqP9FLF-GJDB7Lft9QYTXRRIJGfo8ssL9JNuGINCB7MUANIRH3GkT+kOHNelyl1o4PAFmcEz8EeA+FwiqjA1OXh-V4Re1LOewNEUfrE-1G5DhOSthJRfk/1624979055037 and this is from mod_cosign.so: cosign-serv2=BW5qU8OSJ7e3ldPxzVbccT3BJt8bR4hy43CoaNah8ALS+IEtqCDzLYzLWR7Qb9Bier5O-Q-MTQiKRleiCcxBpRTS7wwEjnJOrwnwuc4+OdwTEg-OkYNmAaEXWVMZ/1624979069 If mod_cosign.so manages a cookie created by the java application it has unpredictable behavior due to this line: cookietime = atoi( misc ); where cookietime is an int. At the moment to work around this problem I have defined two distinct services. I’ve also tested this change to cosign_auth function in filters/apache2/mod_cosign.c: /* if it's a stale cookie, give out a new one */ gettimeofday( &now, NULL ); (void)strtok( my_cookie, "/" ); if (( misc = strtok( NULL, "/" )) != NULL ) { dim = strlen(misc); if (dim > 10) misc[10] = '\0'; cookietime = atoi( misc ); } if (( cookietime > 0 ) && ( now.tv_sec - cookietime ) > cfg->expiretime ) { goto redirect; } With this I can share cookie created by java application in virtualhost protected by mod_cosign.so. I haven't tested if the java filter fails by receiving a cookie created by mod_cosign.so. I would like to know if it is a choice not to be able to have services implemented with different technologies and which share the cookie. Thanks in advance [cid:image001.png@01D76D9A.1D278780] [cid:image002.jpg@01D76D9A.1D278780] Letizia Angela Siri Software Engineer Open Network & Platform Italtel S.p.A. Via Reiss Romoli 20019 Settimo Milanese - MI - Italy email: letiziaangela.s...@italtel.com<mailto:letiziaangela.s...@italtel.com> P: +39 0243881 - +39 0243887195 www.italtel.com<http://www.italtel.com/> [cid:image003.jpg@01D76D9A.1D278780]<http://www.linkedin.com/company/italtel?trk=top_nav_home>[cid:image004.png@01D76D9A.1D278780]<http://www.twitter.com/intent/follow?original_referer=http://twitter.com/goodies2Fbuttons&screen_name=italtel&source=followbutton&variant=2.0> [cid:image005.jpg@01D76D9A.1D278780] <https://www.instagram.com/italtel_hq/> [cid:image006.png@01D76D9A.1D278780] <http://www.youtube.com/user/ItaltelChannel>
_______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
