Access to RegexRegisteredService:serviceId from PrincipalResolver?

63 views
Skip to first unread message

Net Wolf

unread,
Sep 2, 2016, 5:06:55 AM9/2/16
to CAS Community

Hi all, I'm attempting to install and configure CAS 4.2.4 within our environment.


I have LDAP and JDBC authentication working, but would like to supplement the Principal with data from a separate database and use CAS to present a list of "roles" back to the application when a user is authenticated.


I understand I want to chain a couple of PrincipalResolvers together, and although I've not started on that yet, I do think I can figure it out.

However, I'd like to be able to only return the list of "roles" relevant to the application requesting them. 

We have nearly 100 applications we want migrate to CAS and each user may be a member several roles per application. In extreme cases, CAS would be returning up to 500 role names.


I have an InMemoryServiceRegistryDaoImpl configured which allows access from applications within our domain. I have not configured any other serviceRegistry classes.


     <bean

        id="serviceRegistryDao"

        class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">

            <property name="registeredServices">

                <list>

                    <bean class="org.jasig.cas.services.RegexRegisteredService">

                        <property name="id" value="0" />

                        <property name="name" value="HTTP and HTTPS" />

                        <property name="description" value="Allows http[s]://*.internal.company.com[:port]/*" />

                        <property name="serviceId" value="^(http?|https?):\/\/([A-Za-z0-9_-]+)\.internal\.company\.com(:\d{2,5})?\/.*" />

                        <property name="evaluationOrder" value="1" />

                    </bean>

                </list>

            </property>

        </bean>

        

I would like to be able to pass the "$2" item from the serviceId to my PrincipalResolver. 

Alternatively, I could just pass in the whole of the serviceId and do the parsing in the resolver itself.

From my understanding, the Principal is returned by CAS in a separate request (made directly to CAS by the application), so is not really in the context of the serviceRegistry anyway. Given that fact the likelihood of using that regex is very low. However, it's that part of the serviceId that I'd like to query the database with.


How would I gain access to the serviceId detail in the resolver? 

Is there a standard resolver I can use, or would I need to write my own?


Many thanks in advance.

Misagh Moayyed

unread,
Sep 2, 2016, 5:36:35 AM9/2/16
to CAS Community, Net Wolf

Once you have your principal resolver produce a principal with 1000 roles and attributes inside it, all you then have to do is set up attribute release policies to decide what each service would be getting. Either all, or a selection of your “roles” inside the produced principal. 


-- 
Misagh
--
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 post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/15dd9af6-0353-4e1c-893a-bf22e65eb6da%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Net Wolf

unread,
Sep 2, 2016, 5:53:47 AM9/2/16
to CAS Community, netw...@gmail.com, mmoa...@unicon.net
Thanks Misagh. I'll take a look into release policies. 

However, I think only returning the 5 or so relevant records from the DB query seems more efficient.
I also won't know in advance how many rows will be returned by the DB query or what they might be called.

Misagh Moayyed

unread,
Sep 2, 2016, 6:18:47 AM9/2/16
to CAS Community, Net Wolf

There are options for principal resolution that allow you retrieve attributes for a principal that is mapped to a single DB record, or multiple DB records. Look into those, and if insufficient, write/script your own.


If you don’t know what attributes you’d be getting back from the resolver, then there is no way you can make a decision on what each app would receive. You’ve gotta know before you can design that rule. So either you end up releasing everything to the app, (which is probably a bad idea) or you think of some other fancy option like releasing things based on a predefined attribute name pattern…or you learn which attributes each app wants and you get those released out of the principal which is probably something you should do.


-- 
Misagh

From: Net Wolf <netw...@gmail.com>
Reply: Net Wolf <netw...@gmail.com>
Date: September 2, 2016 at 2:53:51 AM
To: CAS Community <cas-...@apereo.org>
--
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 post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.

Net Wolf

unread,
Sep 2, 2016, 7:16:27 AM9/2/16
to CAS Community, netw...@gmail.com, mmoa...@unicon.net
Thanks again Misagh. I'll have a look through those principal resolvers. The multiple record DB one sounds most likely to fit my use case.

As long as I can pass the serviceId into the PrincipalResolver, I can restrict the DB query easily. The serviceId contains the application URL (which contains the application name) and roles are joined against application name in the DB.

So the question is, how do I get the serviceId to the resolver?
Reply all
Reply to author
Forward
0 new messages