Better protocol differentiation

[Jérôme LELEU]

Hi,

I have this SAML SP definition in CAS:

{
  "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
  "serviceId" : "http://localhost:8081.*",
  "name" : "SAMLService",
  "id" : 1,
  "evaluationOrder" : 1,
  "metadataLocation" : "/Users/jleleu/sources/spring-webmvc-pac4j-boot-demo/sp-metadata.xml"
}

And I have realized that I can log in using the CAS protocol with the same service definition :

http://localhost:8080/cas/login?service=http%3A%2F%2Flocalhost%3A8081%2Fcallback%3Fclient_name%3DCasClient

I would have expected the SAML definition not to work for the CAS protocol.

More generally, I have the feeling that protocols are not sufficiently differentiated in CAS.

I'm thinking about the SamlIdPSingleLogoutServiceMessageHandler and the DefaultSingleLogoutServiceMessageHandler components although there might be better examples.

We have built the SAML, OAuth and OIDC protocols on top of the CAS protocol while CAS should be somehow alongside the other protocols.

In terms of design, as a first step, I would make RegexRegisteredService an abstract class and create a CasRegisteredService (inheriting from it) like we have a SamlRegisteredService, a OAuthRegisteredService...

This may be a huge change better targeted at v6.5 or even v7.

Does it make sense?

Thanks.

Best regards,

Jérôme

[Travis Schmidt]

I have solved this in my deployment by having three different ServicesManagers that are chained.  One that is CAS only services, one that is OAuth services and one that is SAML services.  Using the supports() methods to control how a service is selected.  The CAS only uses the friendlyName match to RegexRegisteredService, so having a CasRegisteredService would simplify that to an instanceof check.

Travis

--
You received this message because you are subscribed to the Google Groups "CAS Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-dev+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.

[Daniel Ellentuck]

Hi Jerome, et. al.,

I agree, and that would be a nice first step.  I wound up adding code in which a given registered service is only authorized for use with a specific list of protocols, and an attempt to access the registered service (e.g., by findServiceBy(Service)) for an unauthorized protocol returns null.  

    Dan

Dan Ellentuck

Columbia University I.T.

[Jérôme LELEU]

Hi,

Thanks for the feedback.

@Misagh: do you have any plan on this?

Best regards,

Jérôme

[Misagh]

I suppose there are two things to review:

1. The case you are describing actually works OK for me. If I have a
SAML SP and I try to prevent it's a CAS SP, I correctly get
"application unauthorized". So either something is missing in your
setup, or I am overlooking something. Of course "it works for me"
means nothing. You should likely start with a test case that tries to
reproduce this, with puppeteer specially so we can see where the
problem is. Either way, the @class attribute indicates the allowed
protocol. We shouldn't need to make any other adjustments.

2. For the more general case, I have often thought about going down
the same route as you suggest, to break up CAS SPs into their own
entity and make the regex service some sort of parent abstract entity.
Initial research shows that this is tons of work [never to be
seriously funded by anyone], with potential to break the world with
minor benefits which do not make this worthwhile. If this were to be
done, v7 would be a good target but I would need to be 300% sure this
is necessary, and cannot be fixed/improved in any other "easy" way,
and that it should start with a concrete use case or problem that can
be produced in #1.

> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LwwkU8Y9%2BJ_JbJQMAt%2Be5VoPnXxUkH%2B_e1rzs%2BbEj8Adw%40mail.gmail.com.

[Misagh]

On Fri, Jun 11, 2021 at 11:54 AM Misagh <misagh....@gmail.com> wrote:
> 1. The case you are describing actually works OK for me. If I have a
> SAML SP and I try to prevent it's a CAS SP,

Sorry. I meant "pretend".

[Jérôme LELEU]

Hi,

1. I just tested it again with 6.4.0-RC5 and I still have the issue.

On the client side, I use the pac4j demo: https://github.com/pac4j/spring-webmvc-pac4j-boot-demo on port 8081 (HTTP) : server.port=8081 in the application.properties

On the server side, I use a CAS demo: https://github.com/casinthecloud/cas-overlay-demo on port 8080 (HTTP) run by a Tomcat 9.

I have the SAML IdP dependency:

<dependency>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-support-saml-idp</artifactId>
    <version>${cas.version}</version>
</dependency>

and this JSON definition:

{

  "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
  "serviceId" : "http://localhost:8081.*",
  "name" : "SAMLService",
  "id" : 1,
  "evaluationOrder" : 1,
  "metadataLocation" : "/Users/jleleu/sources/spring-webmvc-pac4j-boot-demo/sp-metadata.xml"
}

From the client demo, I can log in via SAML or via CAS with the following URL: http://localhost:8080/cas/login?service=http%3A%2F%2Flocalhost%3A8081%2Fcallback%3Fclient_name%3DCasClient

With which version did you test it?

2. This is what I feared: breaking the world. I understand the rationale.

Let's solve #1 first.

Thanks.

Best regards,

Jérôme

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkeG6-xPoBi748j56GDyszoWTn%2B9pE7Chp3F-PWJBm3NxA%40mail.gmail.com.

[Misagh]

I might have been a few steps ahead of you. Are you still seeing this
with the latest snapshots?

On Mon, Jun 14, 2021 at 8:09 PM Jérôme LELEU <lel...@gmail.com> wrote:
>
> Hi,
>

[Jérôme LELEU]

Hi,

No, it's fixed with the latest snapshot.

Thanks.

Best regards,

Jérôme

--
You received this message because you are subscribed to the Google Groups "CAS Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-dev+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfQ4rGZ7QCUCFf_%3DpWTP3pdQbuvXVo%2B0qgzABtP%2B%3DwJbg%40mail.gmail.com.