Re: [Cosign-discuss] Cosign cookie question

[Brian Rahn]

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

The server running 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 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 <
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 
> *Inviato:* martedì 29 giugno 2021 19:20
> *A:* Siri Letizia Angela 
> *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
>
>
___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Re: [Cosign-discuss] Cosign cookie question

[Brian Rahn]

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> 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( , 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
>
>
>
> *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 <http://www.italtel.com/>*
>
> <http://www.linkedin.com/company/italtel?trk=top_nav_home>
> <http://www.twitter.com/intent/follow?original_referer=http://twitter.com/goodies2Fbuttons_name=italtel=followbutton=2.0>
>   <https://www.instagram.com/italtel_hq/>
> <http://www.youtube.com/user/ItaltelChannel>
>
>
>
___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Re: [Cosign-discuss] cosign login with krb5 key (or tgt) possible?

[Brian Rahn]

Cosign is firmly tied to using a login & password against a Kerberos realm.
You would not be able to use a keytab or existing Kerberos ticket to
authenticate. The cookies are just random strings used to reference data
stored on the Cosign servers. They do not contain data, nor are they
derived from data.

On Sat, Nov 25, 2017 at 7:20 PM, Chris Hecker  wrote:

>
> I'm hoping the answer is 'no' for my current application, but is there a
> way for a user with a valid krb5 account on the kdc and a keytab file (or
> TGT) for that account to log into cosign without knowing the password used
> to make the key? In other words, there's no way to skip the plaintext
> password entry and pass a key or a TGT directly to cosign, right?
>
> Or, would it be possible to set the cookies correctly manually if the user
> has the key and/or a TGT for the key? It doesn't seem like it from looking
> at the code because then the corresponding cookie file wouldn't exist in
> the /var/cosign/daemon directory, but I wanted to make sure.
>
> Thanks,
> Chris
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Cosign-discuss mailing list
> Cosign-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss