Standalone casserver module vs included casserver module

[pat...@cirrusidentity.com]

There is a separate CAS server module https://github.com/simplesamlphp/simplesamlphp-module-casserver

and a similar, but more basic module included within SSP https://github.com/simplesamlphp/simplesamlphp/tree/master/modules/casserver

The separate module has a lot more features (tickets can be stored in a DB or in memcache and it seems to support more of the optional parts of CAS) than the module included with SSP.

However the separate module doesn't seem to be actively maintained, and uses internal SSP API calls that have been deprecated and removed from the latest SSP

We currently use the basic but were looking at moving to the separate module to take advantage of some of the features.

Should we fix the standalone module? Or port the desired features into the included module? (Yes, I'm volunteering to try doing the work)

If SSP's goal is move non-essential modules out of the base distribution, then it seems to make sense to me to:

* fix the standalone module

* make sure it contains a superset of the functionality of the included module

* remove the included module from a future release of SSP.

Does that make sense to others?

I think having a single casserver module is preferable to keeping two casserver module under the SSP github organization.

thanks,

Patrick

[Bjorn Rohde Jensen]

Hi Patrick,

Thank you for your interest in the CAS server module.

> There is a separate CAS server module
> https://github.com/simplesamlphp/simplesamlphp-module-casserver
> and a similar, but more basic module included within SSP
> https://github.com/simplesamlphp/simplesamlphp/tree/master/modules/casserver
>
> The separate module has a lot more features (tickets can be stored in a DB
> or in memcache and it seems to support more of the optional parts of CAS)
> than the module included with SSP.

The separate module is actually an old fork of the included module with
some bug fixes and a good number of new features added.

> However the separate module doesn't seem to be actively maintained, and
> uses internal SSP API calls that have been deprecated and removed from the
> latest SSP
>

Well, the separate module is actually maintained, but i have been a wee
bit busy this spring, so i havent been keeping up with ssp api changes.

> We currently use the basic but were looking at moving to the separate
> module to take advantage of some of the features.
>
> Should we fix the standalone module? Or port the desired features into the
> included module? (Yes, I'm volunteering to try doing the work)

Of course the separate module should be fixed:) I should be able to get
that done in the next couple of days.

> If SSP's goal is move non-essential modules out of the base distribution,
> then it seems to make sense to me to:
> * fix the standalone module
> * make sure it contains a superset of the functionality of the included
> module
> * remove the included module from a future release of SSP.
>
> Does that make sense to others?
> I think having a single casserver module is preferable to keeping two
> casserver module under the SSP github organization.
>

The current plan for ssp is indeed to move non essential modules out of
the main project and into separate modules installable through
packagist, but it is a work in progress done mostly by Jaime.

> thanks,
>
> Patrick

Yours sincerely,

Bjorn

[Jaime Perez Crespo]

Hi Patrick!

Bjorn is absolutely right. I’d just like to add that the old CAS module being still included within SimpleSAMLphp is my own fault and should be removed in favour of the standalone one. I have it in my to-do list but never got my hands on it...

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Patrick Radtke]

>> However the separate module doesn't seem to be actively maintained, and
>> uses internal SSP API calls that have been deprecated and removed from the
>> latest SSP
>>
>
> Well, the separate module is actually maintained, but i have been a wee
> bit busy this spring, so i havent been keeping up with ssp api changes.

Oh that is great! I just jumped to conclusions.

I have created a PR with some fixes targeted at the login.php page.

https://github.com/simplesamlphp/simplesamlphp-module-casserver/pull/3

The main changes are the start of automated tests to go with the code.
Currently these require you to run the embedded php http server. I
have a project somewhere where the embedded server is started and
shutdown automatically by the tests, I just haven't had the time yet
to find it/port it over. I can do that in a future PR, or I'm open to
a better ways to do automated tests.

>> We currently use the basic but were looking at moving to the separate
>> module to take advantage of some of the features.
>>
>> Should we fix the standalone module? Or port the desired features into the
>> included module? (Yes, I'm volunteering to try doing the work)
>
> Of course the separate module should be fixed:) I should be able to get
> that done in the next couple of days.

Thanks for the help. One thing I wasn't able to figure out was what to
replace the $session->remainingTime() call with.

-Patrick

[Bjorn Rohde Jensen]

Hi Patrick,

> The main changes are the start of automated tests to go with the code.
> Currently these require you to run the embedded php http server. I
> have a project somewhere where the embedded server is started and
> shutdown automatically by the tests, I just haven't had the time yet
> to find it/port it over. I can do that in a future PR, or I'm open to
> a better ways to do automated tests.
>
>

It looks pretty good to me, although unit test frameworks tend to have
issues when used for integration tests :)

In the long run, i think, Travis would be the way to go, in part simply
to conform as much as possible to the simplesamlphp project it self.

>>> We currently use the basic but were looking at moving to the separate
>>> module to take advantage of some of the features.
>>>
>>> Should we fix the standalone module? Or port the desired features into the
>>> included module? (Yes, I'm volunteering to try doing the work)
>>
>> Of course the separate module should be fixed:) I should be able to get
>> that done in the next couple of days.
>

I am pretty sure, i have replaced all uses of deprecated api's, but a
second pair of eyes would be most welcome.

Yours sincerely,

Bjorn

[Patrick Radtke]

> I am pretty sure, i have replaced all uses of deprecated api's, but a
> second pair of eyes would be most welcome.

Thanks. I'll take a look when I deploy some new servers next week.

-Patrick