Service Access Strategy help needed

[Emilian Mitocariu]

Hi, I have a CAS server with a service json that catches all incoming requests looking like this:

{

  "@class": "org.apereo.cas.services.RegexRegisteredService",

  "serviceId": "^(https|http)://.*",

  "name": "HTTPS and HTTP",

  "id": 20000001,

  "description": "This service definition authorizes all application urls that support HTTPS and HTTP protocols.",

  "attributeReleasePolicy" : {

    "@class" : "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"

  },

  "evaluationOrder": 201,"accessStrategy" : {

    "@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",

    "enabled" : true,

    "ssoEnabled" : true,

    "requiredAttributes" : {

      "@class" : "java.util.HashMap",

      "access_app_list" : [ "java.util.HashSet", [ "some-app" ] ]

    }

  }

}

Where access_app_list is retrieved from a DB. My question, is there a built-in variable that I can put instead of some-app that contains the domain of the service accessing CAS? Or do I need to use a groovy script for this? And if groovy is needed, any pointers on how I could do that?

I would like to do this so I don't have to define a different service json for every app that needs to authenticate against CAS.

[Ray Bon]

Emilian,

See https://github.com/apereo/cas-management-overlay for a web application to create services.

The value in creating multiple service entries, lays in security. With your current service id, any application in the world can use your cas to log in.

An additional benefit to having one service definition per service (or maybe a few services) is customization per service. This is for the capabilities/requirements/limitations of the service.

If all of your services really are identical, you can duplicate a service entry and change the serviceId. This would be less work than creating a new process and database and cas modifications.

Ray

On Wed, 2020-07-01 at 04:26 -0700, Emilian Mitocariu wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.

[Bryan Wooten]

I agree with Ron. As a point of reference, we have 1000 json entries in our service registry. I added 6 this morning.

Very few use any wild cards.

We are also working on getting the management app up and running.

-Bryan

University of Utah

--
- 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/fbc184d6-353a-4aaa-887f-acc77e1d4264n%40apereo.org.

[Emilian Mitocariu]

Ok, I'll take your answers into consideration. 

I agree adding new json entries isn't that hard as we won't have new services everyday, it's just that I was asked to look into this strategy among others.

Also, I know having the serviceid like that is going to allow any application to authenticate against our CAS, but I didn't find it that risky as bad intended persons will still need some valid credentials to log into our CAS. Please correct me if I'm wrong.

[Ray Bon]

Emilian,

It opens a vector for phishing, etc, putting your users at risk.

Ray

--