Benito,
This seems fine as far as it goes. If it were in the uPortal product we might
find a use for it in MyUW.
It feels like PAGS is less and less about person attributes and more and more
PAGS is “The Groups System”. Maybe it could be re-named and re-scoped and done
more deliberately for a uPortal 5 or so?
More and more our strategy in MyUW has been to externalize groups management
into Manifest, which is a groups service with among other things Grouper inside
of it. It does data-driven groups and ad-hoc groups and delegated
administration and … But its killer feature is that it’s the enterprise group
store and so group policy problems become less of a portal problem. We pick up
these group memberships via SAML assertions from our friendly neighborhood
Shibboleth IdP, which represents the group memberships we’re entitled to know
about as user attributes.
The technology exists to query the IdP as if it were a directory to ask about
user attributes outside the context of that user logging in. That would get us
back to the ability to ask about the user attributes (and group memberships) of
users outside the context of their very own session. We haven’t actually
implemented this in MyUW yet, but at least one other application on campus is
doing this trick, so there’s some comfort that we could do it if we had to, and
that helps us to feel we’re not missing much moving away from portal-managed
groups and user attributes from LDAP and all that.
In the details, of course, we’re still using PAGS with a PAGS group shadowing
each Manfiest group, with the PAGS group configured to do its testing based on
the user attribute representing that group membership. This is kind of a pain
and from time to time we kick around the idea of implementing something lighter.
I suspect that rather than building out its own group system, uPortal would be
better off internally implementing Grouper, or having something very
lightweight internally for which all the interesting functionality is achieved
by pointing it at an external grouper.
So
<adhoc-group-test>
<include>
<group-name>Students</group-name>
<group-name>Mobile Device Access</group-name>
</include>
<exclude>
<group-name>Testers</group-name>
</exclude>
</adhoc-group-test>
is cute and all, and even practical and useful, and I understand why you’re
building it, and heck I’ll even use it if I end up needing to, but it’s also
kind of a cartoon version of what Grouper does for group math, and there’s some
alternate universe in which uPortal just uses Grouper for this and thereby
realizes that sophistication and we skip this ad-hoc stuff.
That alternate universe may well not co-incide with this universe.
Kind regards,
Andrew
PS : Anathem. Great book.
PPS: How’s the entity-driven-PAGS import-export going for this new
adhoc-group-test featureset?
On May 1, 2015, at 3:57 PM, Benito J. Gonzalez
<[email protected]<mailto:[email protected]>> wrote:
Hi uPortal Devs,
Some of you might recognize my name. I had been with University of California,
Merced for the last 9 years. Recently, I joined Unicon to increase my
participation with this awesome community!
I am currently working on a PAGS tester that will test membership in other
groups. The idea is that this tester will be used to check for membership in
combinations of other groups. This avoids duplication and synchronization of
test criteria.
An example would be a test for persons that are students currently using a
mobile device that are not in a test group. Assuming appropriately named groups:
...
<adhoc-group-test>
<include>
<group-name>Students</group-name>
<group-name>Mobile Device Access</group-name>
</include>
<exclude>
<group-name>Testers</group-name>
</exclude>
</adhoc-group-test>
...
Ramping up on the groups subsystem has been challenging, but I have a working
tester class for a single group check. It currently (mis-) uses the attribute
and value stanzas for the normal tests to allow me to address recursion when
checking for group membership. Working on the changes needed to the import code.
Anyone else interested in this feature? Comments more than welcome.
Benito J. Gonzalez - Unicon
[email protected]<mailto:[email protected]>
480.558.2360
--
You are currently subscribed to
[email protected]<mailto:[email protected]> as:
[email protected]<mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
