Better protocol differentiation

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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 :


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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

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

On Mon, Jun 7, 2021 at 1:07 AM Jérôme LELEU <[hidden email]> wrote:
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 :


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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAC_RtEaqf3adh1QM4La7wVY%2Bpx8%2BVW65MT3M9-cALrwebCp3xw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

Daniel Ellentuck
In reply to this post by Jérôme LELEU
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.


On Mon, Jun 7, 2021 at 4:07 AM Jérôme LELEU <[hidden email]> wrote:
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 :


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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAFqYg5%2B2x1iD_GaZ8NpB%2Bccy57nm%2BhrZZR2tncE2r3-HuJb7jw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

Jérôme LELEU
Hi,

Thanks for the feedback.

@Misagh: do you have any plan on this?

Best regards,
Jérôme


Le lun. 7 juin 2021 à 17:41, Daniel Ellentuck <[hidden email]> a écrit :
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.


On Mon, Jun 7, 2021 at 4:07 AM Jérôme LELEU <[hidden email]> wrote:
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 :


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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

Misagh Moayyed-2
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.

On Fri, Jun 11, 2021 at 10:42 AM Jérôme LELEU <[hidden email]> wrote:

>
> Hi,
>
> Thanks for the feedback.
>
> @Misagh: do you have any plan on this?
>
> Best regards,
> Jérôme
>
>
> Le lun. 7 juin 2021 à 17:41, Daniel Ellentuck <[hidden email]> a écrit :
>>
>> 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.
>>
>>
>> On Mon, Jun 7, 2021 at 4:07 AM Jérôme LELEU <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I have this SAML SP definition in CAS:
>>>
>>> {
>>>   "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
>>>   "serviceId" : "<a href="http://localhost:8081.*">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
>>>
>>> --
>>> 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 [hidden email].
>>> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.
>
> --
> 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 [hidden email].
> 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.

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

Misagh Moayyed-2
On Fri, Jun 11, 2021 at 11:54 AM Misagh <[hidden email]> 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".

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkc0W%2BbNXMZ%3Dt1y9mm%2BUzgxOf%2BCzRUnD6O7NzOnYbnCHLw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

Jérôme LELEU
In reply to this post by Misagh Moayyed-2
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


Le ven. 11 juin 2021 à 09:54, Misagh <[hidden email]> a écrit :
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.

On Fri, Jun 11, 2021 at 10:42 AM Jérôme LELEU <[hidden email]> wrote:
>
> Hi,
>
> Thanks for the feedback.
>
> @Misagh: do you have any plan on this?
>
> Best regards,
> Jérôme
>
>
> Le lun. 7 juin 2021 à 17:41, Daniel Ellentuck <[hidden email]> a écrit :
>>
>> 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.
>>
>>
>> On Mon, Jun 7, 2021 at 4:07 AM Jérôme LELEU <[hidden email]> wrote:
>>>
>>> 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
>>>
>>> --
>>> 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 [hidden email].
>>> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LzNmaCyk1f_ugJRcQbTappYN8zkKZnw6YAfYdyJZpK7HA%40mail.gmail.com.
>
> --
> 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 [hidden email].
> 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.

--
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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LyYWwohXOT31jB51K_9qOZ-U39Lt2n11Hjob1dxBCRwZQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Better protocol differentiation

Misagh Moayyed-2
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 <[hidden email]> wrote:

>
> 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" : "<a href="http://localhost:8081.*">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

--
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 [hidden email].
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.