Home brewed PHP CAS client

Bryan Wooten

unread,

Oct 13, 2018, 8:31:26 AM10/13/18

to cas-...@apereo.org

Hi all,

So I have this one application (PHP on Apache) that wants to write their own CAS PHP client. Yeah a bad idea I know.

Anyway they they don't like mod_auth_cas because it takes auth out of the application and delegates it to Apache? (My opinion is that this is the least effort solution)

They don't like the PHP CAS client because it has a dependency on libcurl? (Apparently ten years ago IT didn't allow libcurl to be installed? Not the case today.)

This idea is going to ISO for approval, but in the meantime I could use all the pros(?)/cons of this approach.

In the event this does get approved what are some behaviors I can monitor on the CAS server side to minimize / test for issues? I know SLO will be a big one as well as session timeout.

Thanks,

Bryan

University of Utah

Tepe, Dirk

unread,

Oct 14, 2018, 9:38:51 AM10/14/18

to cas-...@apereo.org

"they don't like mod_auth_cas because it takes auth out of the application and delegates it to Apache"

This is not true. The authentication is being performed by CAS. The resolution of the asserted identity is being done in Apache via mod_auth_cas. The entire point (and value) of an Identity Provider like CAS is to take authentication out of the application container entirely.

"They don't like the PHP CAS client because it has a dependency on libcurl"

If they have an opinion contrary to the implementation in an open source project, they should consider enhancing said project rather than starting over. Replacing the http handler in the application is far less work than creating an entirely new implementation of the overall protocol and others in the community may find the work valuable as well.

"This idea is going to ISO for approval"

This should be an easy call for an ISO. You have to choose an implementation for software which will play a critical role in your application risk profile. On one hand, you have a choice of mature, tested, community supported solutions. On the other hand, you have unproven, in-house code which must implement a complex protocol absolutely correctly and be sustained as changes occur in the future. I don't even have to ask my ISO about something like this.

IMHO, this is simply a non-starter. The on-going responsibility for sustaining a custom CAS client, and the consequences for getting any part of it wrong, should make the cost/benefit analysis straight-forward.

-dirk

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAG9x2GUnBYY%2BsyxM9xLFXML1scccEcgcmGPpxkW6yEzBpVGhMw%40mail.gmail.com.