Groovy scripting support for attribute resolution

[mmoayyed]

There are a number of options for attribute resolution in CAS:

• Static XML requests out to a data store
• JSON file, maps user ids to attributes

Consider providing groovy scripting support that attributes be evaluated based on compilation and execution of a groovy script. This helps with more complicated nesting, cascading and merging use cases for which the person directory API would just be too cumbersome to use.

Resource: http://groovy.codehaus.org/Embedding+Groovy

[apetro]

Is it time to create Unicon/person-directory-addons to better set up potential for pushing person directory enhnancements out into the person directory product itself, for the potential benefit of both CAS and uPortal?

[dima767]

It sure does feel like these person dir components belong in a separate project. +1 for inventing a separeate one e.g. net.unicon.cas:person-dir-addons and moving all the existing person dir code there. — Sent from Mailbox for iPhone

On Wed, Aug 7, 2013 at 8:02 AM, Andrew Petro notifications@github.com wrote:

Is it time to create Unicon/person-directory-addons to better set up potential for pushing person directory enhnancements out into the person directory product itself, for the potential benefit of both CAS and uPortal?

Reply to this email directly or view it on GitHub: https://github.com/Unicon/cas-addons/issues/40#issuecomment-22246146

[wgthom]

Thoughts on adopting Shib attribute resolution for this?

On Wed, Aug 7, 2013 at 8:12 AM, Dmitriy Kopylenko notifications@github.comwrote:

It sure does feel like these person dir components belong in a separate project. +1 for inventing a separeate one e.g. net.unicon.cas:person-dir-addons and moving all the existing person dir code there. — Sent from Mailbox for iPhone

On Wed, Aug 7, 2013 at 8:02 AM, Andrew Petro notifications@github.com wrote:

Is it time to create Unicon/person-directory-addons to better set up potential for pushing person directory enhnancements out into the person directory product itself, for the potential benefit of both CAS and

uPortal?

Reply to this email directly or view it on GitHub: https://github.com/Unicon/cas-addons/issues/40#issuecomment-22246146

— Reply to this email directly or view it on GitHubhttps://github.com/Unicon/cas-addons/issues/40#issuecomment-22246595 .

[dima767]

From me - negative. Too complected with Shib machinery. Too complex. I'd rather stay away from it.  — Sent from Mailbox for iPhone

On Wed, Aug 7, 2013 at 8:28 AM, William G. Thompson, Jr. notifications@github.com wrote:

Thoughts on adopting Shib attribute resolution for this? On Wed, Aug 7, 2013 at 8:12 AM, Dmitriy Kopylenko notifications@github.comwrote:

It sure does feel like these person dir components belong in a separate project. +1 for inventing a separeate one e.g. net.unicon.cas:person-dir-addons and moving all the existing person dir code there. — Sent from Mailbox for iPhone

On Wed, Aug 7, 2013 at 8:02 AM, Andrew Petro notifications@github.com wrote:

Is it time to create Unicon/person-directory-addons to better set up potential for pushing person directory enhnancements out into the person directory product itself, for the potential benefit of both CAS and

uPortal?

Reply to this email directly or view it on GitHub: https://github.com/Unicon/cas-addons/issues/40#issuecomment-22246146

— Reply to this email directly or view it on GitHubhttps://github.com/Unicon/cas-addons/issues/40#issuecomment-22246595 .

---

Reply to this email directly or view it on GitHub: https://github.com/Unicon/cas-addons/issues/40#issuecomment-22247290

[epierce]

On the one hand the Shib resolver does just about anything you can imagine with creating/modifying attributes. On the other, the configuration is so arcane it's really painful to work with.

[apetro]

A wise man once counseled me to take care when I'm thinking tactically and when I'm thinking strategically, and separate these.

Tactically: cas-addons (and uPortal!) already have PersonDir extensions / improvements, have fine ideas for more. Tactically, we could better organize the code we've already got for better clarity, for better re-usability, for a clearer path to some rage-driven-development of better logging and alternative configuration mechanisms. Let's enable that. It's real work, but it's a modest investment, with good return on immediate supportability and enabling tactical innovation / fixing and better collaboration between CAS and uPortal practices within and beyond Unicon on how to iteratively improve PersonDir.

Strategically: maybe PersonDir just isn't the right library to be using for CAS attributes. Great. Refactoring it out of cas-addons is incidentally a fine step in that direction. :)

I advocate inventing unicon/person-dir-addons as a modest tactical move to make things Better, and not letting strategic possibilities distract from realizing that bit of Better. :)

And, sure, a fine Issue to create inside that new person-dir-addons would be the proposal for a PersonAttributeDao implementation that bridges to the Shibboleth attribute resolver implementation and configuration. That would enable CAS adopter experimentation with whether that power and configuration language meets needs.

[apetro]

Added wontfix label indicating that it won't be fixed here in cas-addons and instead needs moved to the new person-dir-addons repo.

[mmoayyed]

So, who's going to own the task of creating the person-dir-addons repo?

[dima767]

Misagh, if you have some breathing room, would you mind giving it a shot? The sub-groupId would be net.unicon.persondir and the artifactId person-dir-addons, I guess.

[dima767]

Then we could also move our existing JsonPersonAttr Dao there ( tracked as #41 )

[mmoayyed]

Moved issue.