[Cosign-discuss] R: Cosign cookie question

2021-07-01 Thread Siri Letizia Angela
Thank you very much Brian, this is a great solution.

I have tested it in our project and it works perfectly.

I apologize if I disturbed, in fact in the file cosign.conf.5 this possibility 
was described, but the project is old and the current configuration did not 
foresee the use of regular expressions.

In the next release I think I will use them as you indicated.

Thank you

Letizia Siri

Da: Brian Rahn 
Inviato: mercoledì 30 giugno 2021 16:42
A: Siri Letizia Angela 
Cc: cosign-discuss@lists.sourceforge.net
Oggetto: Re: Cosign cookie question

We solve that in our own installation with a default rule that uses regular 
expressions:
service cosign-(.*)  
https://$1.umich.edu/cosign/valid<http://1.umich.edu/cosign/valid>  0  
(.*)\.umich.edu<http://umich.edu>cosign-$1

The server running www.umich.edu<http://www.umich.edu> has a service name of 
cosign-www. Users are redirected to https://www.umich.edu/cosign/valid. The 
servers use their www.umich.edu<http://www.umich.edu> certificate to connect 
back to cosignd. That means new services can join the Cosign SSO without any 
changes on the Cosign side.

Brian Rahn

On Wed, Jun 30, 2021 at 4:53 AM Siri Letizia Angela 
mailto:letiziaangela.s...@italtel.com>> wrote:
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 mailto:bdr...@umich.edu>>
Inviato: martedì 29 giugno 2021 19:20
A: Siri Letizia Angela 
mailto:letiziaangela.s...@italtel.com>>
Cc: 
cosign-discuss@lists.sourceforge.net<mailto: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
___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss


[Cosign-discuss] Cosign cookie question

2021-06-29 Thread Siri Letizia Angela
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( , 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:image002.png@01D76D16.7ADAD9B0]
[cid:image003.jpg@01D76D10.FB2CCAC0]
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
P: +39 0243881 - +39 0243887195
www.italtel.com
[cid:image004.jpg@01D76D10.FB2CCAC0]
 [cid:image005.png@01D76D10.FB2CCAC0] 

  [cid:image006.jpg@01D76D10.FB2CCAC0]   
[cid:image007.png@01D76D10.FB2CCAC0] 


___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss