On Tue, 3 Jan 2012, Andrew Petro wrote:
Andy,
Off hand, here's what I'd think about:
1) Why are you restricting CAS usage to registered services? If you
want to let any service use CAS, would you be happier adding an
http://** entry? If you don't want to let any service use CAS, then is
it okay to let anyone run a service on their localhost and use CAS?
2) localhost isn't going to work for getting PGTs, since the CAS server
won't be able to address the service to do the callback request. To the
extent that this developer wants to mess with proxy tickets, merely
registering "localhost" isn't going to meet his needs.
3) Would you rather meet this need by asking this developer to run a
development CAS instance on his desktop? You're probably not willing to
release interesting attributes from your institutional CAS server to
"localhost", so a naive localhost deployment of the CAS quick start .war
might be functionally equivalent.
4) Would you rather meet this need by running a non-production
development instance of the CAS server with a more permissive
configuration, so as to not introduce this service registration to your
production CAS server?
If it were me, if I weren't willing to register http://**, I wouldn't be
willing to register http://localhost . And if I were willing to
register http://**, then I wouldn't have to register http://localhost.
:)
Thanks for the feedback Andrew! I ended up creating a service
"http*://localhost:*/**" on our DEV CAS instance and only releasing the
username attribute.
Andy
--
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/cas-user
