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. :) Kind regards, Andrew On Jan 3, 2012, at 11:53 AM, Andrew Morgan wrote: > One of our developers has asked me to create a CAS service entry for > http://localhost. He does development work on his local machine. Are there > any issues I should be aware of before I create this service entry? > > Thanks, > 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 -- 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
