Thank you, Misagh, for clarifying. It makes sense to me now. My situation is not too complicated, so it should be relatively easy to deploy.
>-----Original Message----- >From: Misagh Moayyed [mailto:[email protected]] >Sent: Tuesday, January 27, 2015 3:21 PM >To: [email protected] >Subject: RE: [cas-user] question about Service Management > >Your management app can be protected by a CAS server, amongst other >methods. When you try to access it, it will be treated as just any other web >application trying to use CAS for SSO, which means if you are using MySql for >authentication as the backend account store for CAS itself, you can use the >same credentials to get into the management app, but that's only half of the >story. The other half is, you need to authorize who is allowed to get into the >management app and a simple way to do that is to use the user- >details.properties file. That will list the accounts/users that are both >authenticated and authorized to make changes via the management app. You >can also change this behavior, if you'd rather not use the file, to look at >ldap >groups and so on for authorization, etc. > >-----Original Message----- >From: Chris Adams [mailto:[email protected]] >Sent: Tuesday, January 27, 2015 4:00 PM >To: [email protected] >Subject: RE: [cas-user] question about Service Management > >Thank you, all, for your advice about managing services. > >I am still a bit confused about authentication. The docs say: > > >"By default, the cas-management-webapp is configured to authenticate >against a CAS server. We assume that it's the case in this documentation. >However, you could change the authentication method by overriding the >WEB-INF/spring-configuration/securityContext.xml file. >Securing Access and Authorization/ " > >Currently, my CAS server is using a MySQL db for authenticating users. Is this >the authentication that is being referred to in the above statement ? > > > >"Access to the management webapp is controlled via Spring Security. Rules >are defined in the /cas-management-webapp/src/main/webapp/WEB- >INF/managementConfigContext.xml >file. >Static List of Users. By default, access is limited to a static list of users >whose >credentials may be specified in a user-details.properties file that should be >available on the runtime classpath." > > >So, this is authentication for users of the management webapp. Again, what is >the authentication referred to as the default authentication method in the >first statement.? > > >A little clarification would be most helpful. > >Many thanks. > > > > > > > > > > > >>-----Original Message----- >>From: [email protected] >>[mailto:[email protected]] On Behalf Of Milt Epstein >>Sent: Tuesday, January 27, 2015 11:02 AM >>To: [email protected] >>Subject: Re: [cas-user] question about Service Management >> >>To echo Carl's comments, I think it's a good idea to use at least a >>lightweight service manager. If it works for you, might I suggest the >>Unicon YAML Service Registry addon (it works at least with CAS 4.0.X). >> >>Configuration is easy, assuming you're using the Maven overlay method >>-- one additional dependency in pom.xml, one additional config file >>src/main/webapp/WEB-INF/spring-configuration/servicesRegistry.xml, and >>the YAML services registry file itself servicesRegistry.yml (exact >>location specified by the aforementioned servicesRegistry.xml). >> >>More documentation can be found online (I can probably find the link >>for that if searching doesn't yield anything helpful). >> >>Limitations are that there's no web interface for managing services, >>and you need to modify the file servicesRegistry.yml to make changes >>(changes are recognized instantaneously when the file is changed/saved). >> >>CAS 4.1 (in development) includes a facility for service registry using >>a JSON file. I'm not familiar with the details of that. >> >>Milt Epstein >>Applications Developer >>Graduate School of Library and Information Science (GSLIS) University >>of Illinois at Urbana-Champaign (UIUC) [email protected] >> >> >>On Tue, 27 Jan 2015, Waldbieser, Carl wrote: >> >>> Chris, >>> >>> It is true, you don't need to use a Service Manager, but that means >>> that >>*any* service can use your CAS. This might not be what you want-- a >>rouge service provider could leverage your CAS in order to fool your >>users into thinking it is trustworthy service. Once authenticated, it >>may ask for sensitive information. So while the rouge service can't >>get user's password, it could potentially trick them into revealling >other PII. >>> >>> CAS needs to run as an HTTPS site-- the TGT is stored in a secure >cookie. >>> Services don't *have* to be HTTPS unless they want to leverage PGTs, >>> but in >>practice it makes sense to secure services in many cases. >>> >>> Thanks, >>> Carl Waldbieser >>> ITS System Programmer >>> Lafayette College >>> >>> ----- Original Message ----- >>> From: "Chris Adams" <[email protected]> >>> To: [email protected] >>> Sent: Tuesday, January 27, 2015 12:53:15 PM >>> Subject: [cas-user] question about Service Management >>> >>> Hello all, >>> >>> I was just looking in to building the Service Management module, as I >>assumed it was required. >>> >>> I am utilizing CAS for SSO for a handful of services. From the CAS >>documentation, it says: >>> >>> "It is not required to use the service management facility >>> explicitly. CAS >>ships with a default configuration that is suitable for deployments >>that do not need or want to leverage the capabilities above. The >>default configuration allows any service contacting CAS over >>https/imaps to use CAS and receive any attribute configured by an >IPersonAttributeDao bean." >>> >>> Does that mean that I don't have to register these services if I >>> don't need to >>manage them with this interface? Can I just append the URL of the >>service to the CAS server login string and be done with it ? >>> >>> Also, somewhere in the docs, it said that any serviced also had to >utilize SSL. >>Can someone verify that ? >>> >>> Many thanks, >>> >>> Christopher Adams >>> >>> -- >>> 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 >>> >> >>-- >>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 > > >-- >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
