[cas-user] service manager application authorization via LDAP
We are testing out CAS; so far I have successfully installed 3.5.2 and configured it to authenticate against our LDAP directory. By updating the sec:user-service configuration to include my username, I am able to access the service management application. However, I would like to configure it to do authorization based on LDAP group membership, not statically listed usernames. Following the guide at: https://wiki.jasig.org/display/CASUM/Configuring I replaced sec:user-service with sec:ldap-server and org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'scheduler' define d in ServletContext resource [/WEB-INF/spring-configuration/applicationContext.xml]: Invocation of init m ethod failed; nested exception is org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [org.springframework.security.ldap.DefaultSpringSecurityContextSource] for bean with name 'ldapServer' defined in null; nested exception is java.lang.ClassNotFoundException: org.springframework.secur ity.ldap.DefaultSpringSecurityContextSource I determined I needed to add a dependency on spring-security-ldap, so I updated my pom.xml: org.springframework.security spring-security-ldap 3.1.4.RELEASE and rebuilt, resulting in: java.lang.NoSuchMethodError: org.springframework.web.context.support.XmlWebApplicationContext.getEnvironm ent()Lorg/springframework/core/env/ConfigurableEnvironment; After beating my head against the wall for a while, I figured out that somehow adding this dependency resulted in multiple versions of some jars ending up in the war maven created: WEB-INF/lib/spring-aop-3.0.7.RELEASE.jar WEB-INF/lib/spring-aop-3.1.1.RELEASE.jar WEB-INF/lib/spring-asm-3.0.7.RELEASE.jar WEB-INF/lib/spring-asm-3.1.1.RELEASE.jar WEB-INF/lib/spring-beans-3.0.7.RELEASE.jar WEB-INF/lib/spring-beans-3.1.1.RELEASE.jar WEB-INF/lib/spring-context-3.0.7.RELEASE.jar WEB-INF/lib/spring-context-3.1.1.RELEASE.jar WEB-INF/lib/spring-core-3.0.7.RELEASE.jar WEB-INF/lib/spring-core-3.1.1.RELEASE.jar WEB-INF/lib/spring-security-core-3.1.0.RELEASE.jar WEB-INF/lib/spring-security-core-3.1.4.RELEASE.jar WEB-INF/lib/spring-tx-3.0.7.RELEASE.jar WEB-INF/lib/spring-tx-3.1.1.RELEASE.jar I tried changing the version from 3.1.4.RELEASE to 3.1.0.RELEASE to match the version of spring-security-core that I guess cas depends on, which got rid of the duplicated spring-security-core jar but still left duplicates: WEB-INF/lib/spring-aop-3.0.6.RELEASE.jar WEB-INF/lib/spring-aop-3.1.1.RELEASE.jar WEB-INF/lib/spring-asm-3.0.6.RELEASE.jar WEB-INF/lib/spring-asm-3.1.1.RELEASE.jar WEB-INF/lib/spring-beans-3.0.6.RELEASE.jar WEB-INF/lib/spring-beans-3.1.1.RELEASE.jar WEB-INF/lib/spring-context-3.0.6.RELEASE.jar WEB-INF/lib/spring-context-3.1.1.RELEASE.jar WEB-INF/lib/spring-core-3.0.6.RELEASE.jar WEB-INF/lib/spring-core-3.1.1.RELEASE.jar If I remove the dependency on spring-security-ldap, there are no duplicated spring jars. What am I doing wrong here? java gives me a headache . Thanks much… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] service manager application authorization via LDAP
On Thu, Aug 01, 2013 at 07:21:54PM -0700, Paul B. Henson wrote: > After beating my head against the wall for a while, I figured out that > somehow adding this dependency resulted in multiple versions of some > jars ending up in the war maven created: I managed to work around this by adding explicit exclusions to pom.xml: org.springframework.security spring-security-ldap 3.1.1.RELEASE org.springframework spring-aop org.springframework spring-tx org.springframework spring-beans org.springframework spring-context org.springframework spring-core Is that really what needed to be done? Seems awfully manual as a process; scan war for duplicate jars and go list them one by one? Then I had the error: Error creating bean with name 'casAuthenticationProvider' defined in ServletContext resource [/WEB-I NF/spring-configuration/securityContext.xml]: Cannot resolve reference to bean 'userDetailsService' while setting bean property 'userDetailsService'; nested exception is org.springframework.beans.factory.NoSuch BeanDefinitionException: No bean named 'userDetailsService' is defined Looks like there's a typo on the configuration wiki page? The example config is listed as sec:ldap-user-service id="userService" evidentally it should be sec:ldap-user-service id="userDetailsService" Well, now I'm getting "Access Denied", so I guess the job for tomorrow is to figure out how to map an ldap group into the role the service management app wants to see to authorize access... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] service manager application authorization via LDAP
On 8/1/2013 10:54 PM, Misagh Moayyed wrote:
> Thanks for catching the typo. I updated the wiki.
Cool. In the example, it lists "${spring.security.ldap.version}" for the
version, but the built will fail unless that is defined somewhere. I
suppose for someone with maven experience that will be obvious, but
before my crash course yesterday ;) I would have just copied it
literally and ended up with:
[ERROR] 'dependencies.dependency.version' for
org.springframework.security:spring-security-ldap:jar must be a valid
version but is '${spring.security.ldap.version}'. @ line 44, column 13
and been confused. Is there any way for the cas pom configuration to
define versions that are inherited by the local pom? Otherwise, you have
to go figure out what version of spring the version of cas you are
building uses, and what version of spring.security.ldap is appropriate
for it. Ideally a user would just have to add a dependency and not worry
about coordinating the version.
I get the impression not many people actually try to do LDAP
authorization for the services manager? I think we're going to end up
using the JSON backend and not edit the entries through the GUI anyway.
I understand in CAS 4 the service manager app is separate, rather than
bundled, we probably won't install it at that point. However, the
current version has a statistics panel that might be interesting to look
at, so it seems worth getting going.
> I am guessing that the version of spring that "spring-security-ldap"
> depends on is different than what other dependencies in the pom use. (You
> could check this by running mvn dependency:tree from the command prompt)
> and so because it doesn't find them, it needs to exclusively bring them
> down. Excluding them manually is the way to prevent that.
Yes, that is the case. Perhaps I'm mistaken, but I didn't think it was
possible for a given java application to use more than one version of a
given class? So if two different versions of the same jar exist, it's
going to use whichever one it finds first?
If that is true, isn't it rather broken to build a war with multiple
versions of the same jar? It seems maven should complain rather than
letting somebody go install a war with potentially undefined behavior.
Even without the extra spring LDAP dependency, I find multiple versions
of three jars in my war:
WEB-INF/lib/commons-collections-3.2.1.jar
WEB-INF/lib/commons-collections-3.2.jar
WEB-INF/lib/javassist-3.15.0-GA.jar
WEB-INF/lib/javassist-3.7.ga.jar
WEB-INF/lib/stax-api-1.0-2.jar
WEB-INF/lib/stax-api-1.0.1.jar
Interestingly, unlike the case with spring LDAP, I don't find them in
the dependency list? I'm not sure where they are coming from.
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | hen...@csupomona.edu
California State Polytechnic University | Pomona CA 91768
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-userWEB-INF/lib/activation-1.1.jar
WEB-INF/lib/antlr-2.7.7.jar
WEB-INF/lib/aopalliance-1.0.jar
WEB-INF/lib/aspectjrt-1.6.10.jar
WEB-INF/lib/aspectjweaver-1.6.10.jar
WEB-INF/lib/bcprov-jdk15-1.45.jar
WEB-INF/lib/cas-client-core-3.2.1.jar
WEB-INF/lib/cas-server-core-3.5.2.jar
WEB-INF/lib/cas-server-support-ldap-3.5.2.jar
WEB-INF/lib/cglib-nodep-2.2.2.jar
WEB-INF/lib/commons-beanutils-1.7.0.jar
WEB-INF/lib/commons-codec-1.4.jar
WEB-INF/lib/commons-collections-3.2.1.jar
WEB-INF/lib/commons-collections-3.2.jar
WEB-INF/lib/commons-httpclient-3.1.jar
WEB-INF/lib/commons-io-2.0.jar
WEB-INF/lib/commons-jexl-1.1.jar
WEB-INF/lib/commons-lang-2.5.jar
WEB-INF/lib/commons-logging-1.1.jar
WEB-INF/lib/dom4j-1.6.1.jar
WEB-INF/lib/esapi-2.0GA.jar
WEB-INF/lib/ezmorph-1.0.4.jar
WEB-INF/lib/hibernate-commons-annotations-4.0.1.Final.jar
WEB-INF/lib/hibernate-core-4.1.0.Final.jar
WEB-INF/lib/hibernate-jpa-2.0-api-1.0.1.Final.jar
WEB-INF/lib/hibernate-validator-4.2.0.Final.jar
WEB-INF/lib/inspektr-audit-1.0.7.GA.jar
WEB-INF/lib/inspektr-common-1.0.7.GA.jar
WEB-INF/lib/inspektr-error-1.0.7.GA.jar
WEB-INF/lib/inspektr-support-spring-1.0.7.GA.jar
WEB-INF/lib/javassist-3.15.0-GA.jar
WEB-INF/lib/javassist-3.7.ga.jar
WEB-INF/lib/jaxb-api-2.2.jar
WEB-INF/lib/jaxb-impl-2.2.jar
WEB-INF/lib/jboss-logging-3.1.0.CR2.jar
WEB-INF/lib/jboss-transaction-api_1.1_spec-1.0.0.Final.jar
WEB-INF/lib/jcip-annotations-1.0.jar
WEB-INF/lib/jcl-over-slf4j-1.7.1.jar
WEB-INF/lib/jdom-1.0.jar
WEB-INF/lib/jettison-1.0.1.jar
WEB-INF/lib/joda-time-2.1.jar
WEB-INF/lib/json-lib-2.2.3-jdk15.jar
WEB-INF/lib/jstl-1.1.2.jar
WEB-INF/lib/jul-to-slf4j-1.6.1.jar
WEB-INF/lib/junit-3.8.1.jar
WEB-INF/lib/log4j-1.2.15.jar
WEB-INF/lib/not-yet-commons-ssl-0.3.9.jar
WEB-INF/lib/ognl-2.7.3.jar
WEB-INF/lib/opensaml-2.5.1-1.
[cas-user] fault-tolerant/redundant/HA CAS deployment
I finished setting up an initial standalone CAS server, and am now moving on to getting redundant servers set up behind a load balancer. The first page of the documentation (https://wiki.jasig.org/display/CASUM/Home) says: Additionally, session state replication is unnecessary since tickets stored in the registry contain the authenticated state of users, which allows a CAS server node to fail without users losing their SSO session state. OTOH, the documentation on clustering (https://wiki.jasig.org/display/CASUM/Clustering+CAS) says: Since CAS stores the login information in the application session we need to setup session replication between our Tomcat instances. It looks like the main page of the documentation was never updated after the transition to Spring Webflow 2.0+, which per the clustering page lost the ability to store sessions on the client side? So my understanding of the current state is that you must replicate both tomcat sessions as well as use a replicated ticket registry to accomplish clustering? We are initially planning to deploy 2-3 instances in our local data center, but eventually plan to deploy at least one at our remote DR site. From an initial review of the available ticket registry implementations, it looks like either the ehcache or memcache options would best suit our needs (I don't really want to involve a database in our CAS deployment). Is either of those better supported/more popular than the other? It looks like the default for both ticket registry replication and tomcat session registration uses multicast with autodiscovery, without any apparent encryption/authentication/authorization layer? I wouldn't be on board with that just in my own data center :), for replication to the remote DR site that's definitely a no go. The cluster page says "Implementing clustering introduces CAS server security concerns", which is understandable, but I can't find any documentation or discussion as far as alleviating them? For those people doing clustering, what approaches are you taking to make the replication secure? Thanks for any feedback… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/5/2013 1:43 PM, Aaron Bennett wrote: Did you get any decent response from this? Not yet; but I did send the initial query late on a Friday, so I'm hoping maybe a few will trickle in over the course of the week :). compose a similar email when I saw yours. I'm hoping I can just use an mmcache ticket registry and let a hardware Load Balancer take care of the session stuff, but the documentation is a little outdated and inconsistent. Yes; it's a touch disappointing that a security product doesn't have a little bit better documentation on setting it up securely ;), but open source documentation is only as good as the people that contribute to it, so I suppose if I get a reasonably secure replication mechanism set up I should add it to the wiki... Right now I'm prototyping ehcache based ticket replication, initially with the manual peer discovery and no transport security just to make sure it works and see what the traffic pattern is like. Once I get it working I'm probably going to try and tunnel it through ssh port forwarding to encrypt the transport layer. It would be nice if the replication partners could actually authenticate/authorize each other directly, but if I can get them to listen on/connect to loopback and pass all the traffic through the ssh tunnel that will probably be good enough. Once I get that working, I'm probably also going to try and cluster the underlying tomcat sessions. While a load balancer with sticky session support can work around not replicating that data, if you drop a server all of the people with sessions on that one will have to re-authenticate on the other one. Depending on your requirements that might be fine, but I'd rather avoid it. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] ehcache logging
I'm testing out ehcache based ticket replication, and it seems the ehcache code logs connection failures at DEBUG level: 2013-08-05 17:44:39,624 DEBUG [net.sf.ehcache.distribution.ManualRMICacheManagerPeerProvider] - Looking up rmiUrl //ned:41001/org.jasig.cas.ticket.ServiceTicket through exception Connection refused to host: ned; nested exception is: If I end up going into production, I'd really prefer to see at least warnings, if not errors, if for some reason the cache peers are failing to communicate (say, for example, a firewall rule was misconfigured). There's a *lot* of debugging logs that don't really need to be seen on a production system, so I'd rather not leave it at such a high log level. I'm guessing there's no way to fix this short of recompiling that code? And it appears that's in upstream ehcache code, not cas specific code? For those using ehcache, how do you keep track of communications failures or other ehcache issues? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/5/2013 7:37 PM, Pierce, Eric wrote: The tomcat session is only used during the initial authentication - it's just there to keep track of where the user is in the webflow during login. Once a user has authenticated and the TGT has been sent, the tomcat session isn't needed. If you lose a server, anyone who is in the process of logging in will see the login screen again, but as long as the ticket registry is replicated, anyone who has a CAS session will be fine. Ah, I think I misunderstood the documentation and the various mailing list messages I read then. I was under the impression that not replicating tomcat session state would result in all users having to re-authenticate if they hit a different server. And I was actually seeing that behavior during testing, but it turns out that was because I had a typo in my ehcache config and it was successfully replicating service tickets but not TGT's 8-/. Once I fixed that, I was able to failover between the two test servers without having to re-authenticate once I had acquired a TGT. So the window of failure caused by not replicating tomcat session state is only as big as the amount of time between the user first loading the form requesting authentication and then submitting it; given that, I don't think it's worth the extra effort to replicate tomcat sessions after all. Thanks for the clarification… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] ehcache logging
On 8/5/2013 8:15 PM, Scott Battaglia wrote: This isn't really a long term solution but you should be able to set your default logging level to WARN and then set net.sf.ehcache.distribution.ManualRMICacheManagerPeerProvider explicitly to DEBUG. This will at least show them in the production logs. Ah, I didn't think of that; currently I have all of net.sf.ehcache set to DEBUG. OTOH, I wonder what other logging in the other pieces of that package they have at DEBUG that I'd probably want to see… Thanks for the suggestion… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] reload log4j config dynamically
I've externalized my log4j config, and ideally would like to be able to dynamically reload it when it changes without having to restart cas. It looks like there are a handful of different ways in general to have log4j watch its config file and reload it, is there any specific one that would work best within cas? Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/6/2013 2:13 AM, Jérôme LELEU wrote: For those who complain about the "poor" documentation, I advice you to search accross the mailing lists. I did spend a fair amount of time on Google, and poking through the mailing list archives. I did find some helpful information, but nothing really authoritative or comprehensive. Perhaps I missed some of the threads, if there are really good discussions of the topics, maybe links to the threads could be added on the wiki page to make them easier to find? Memcached is more performant than EhCache globally, but what really makes the difference is the serialization through the Kryo library (instead of the Java serialization). My concern on memcached is that it shards the tickets, and if you lose any given memcached node, users will be affected and have to reauthenticate. From that perspective, ehcache, with a fully distributed cache, seems preferable. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Clustering and TGC Visibility
On 8/6/2013 7:55 AM, Whittaker, Geoffrey wrote: p:cookieDomain in ticketGrantingCookieGenerator.xml and warnCookieGenerator.xml on both servers is set to the same value. Just to clarify the involvement of cookieDomain in clustering, it looks like out of the box there is no explicit cookiedomain set in these files? And on my browser, the cookie domain is the FQDN of the CAS server. Assuming your cluster members are behind a load balancer or in some other way all respond to the same name, there's no need to explicitly set cookieDomain, correct? You only need to set that if your individual cluster members are accessed explicitly (ie, cas1.cas.test.org, cas2.cas.test.org) in which case it would need to be set to the common subdomain (cas.test.org)? Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] reload log4j config dynamically
On 8/6/2013 11:34 AM, Misagh Moayyed wrote: CAS should support that behavior already. The log4j configuration is set to refresh at minute intervals. You can override the interval by defining a "log4j.refresh.interval" in your cas.properties file. The value is in milliseconds. Ah, I didn't notice that; I didn't expect it to be so easy ;). Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/6/2013 2:13 PM, Andrew Morgan wrote: As others have said on the mailing list before, is it really that big of a deal if people have to reauthenticate? If there is no concern about users reauthenticating, why not just skip CAS completely and have them authenticate directly to each app ;)? But on a more serious note, if there is an option that avoids failure for a certain scenario, and one that doesn't, barring other criteria clearly the first option is preferable. It sounds like one criteria in which memcached might beat ehcache is in generating less network traffic for the replication. For our circumstances, whether that outweighs the simplicity of not including another moving part and the greater reliability of a fully replicated cache is yet to be determined. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/7/2013 7:08 AM, Jérôme LELEU wrote: Memcached processes can crash but it never happens for us It's not just a matter of unplanned downtime; we deploy updates and patches and do other routine maintenance on a regular basis. With the memcached ticket registry, if we intentionally pull out a server for maintenance, cache data is lost. With ehcache, it is not. At this point, my short comparison list is: ehcache: native java, no extra moving parts (+) fully replicated cache (+) potentially more bandwidth intensive (-) memcached: extra piece to install/configure (-) lost data on failure (-) potentially less bandwidth intensive (+) Neither one has any built in security for replication, so they both will require either ssh tunnels or point-to-point VPNs for the communications layer. Definitely interested in more bullet points either way :). Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] Show of hands – clustering? Which backend?
I'm still reviewing the clustering options for CAS, I haven't been able to get a feeling for how popular each option is. If you are currently clustering CAS, could I trouble you just to reply with which backend you are using? Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] Re: [cas-user] RE: [cas-user] Show of hands – clustering? Which backend?
On 8/7/2013 11:50 AM, Danner, Mearl wrote: Using ehcache on a test cluster. It is what we will implement in production. Cool. Could I trouble you to share your ticketRegistry.xml and ehcache.xml? I pieced mine together from the outdated wiki and various mailing list and blog postings, and I don't have complete confidence in it :). I originally instantiated the EhCacheManagerFactoryBean with an externalized configLocation of /etc/cas/ecache.xml, it found that configuration and appeared to create the cas specific cache pieces, but then it also completed it couldn't find classpath:ecache.xml and said it was configuring based on ecache-failsafe.xml. I ended up moving my configuration to classpath:ecache.xml, which got rid of the failsafe warning, but it still looks like it's reading the configuration twice instead of just once. It also seems to only be bootstrapping the service ticket cache on startup, not the ticket granting ticket cache. Have you/are you planning to do any tuning of the garbage collection parameters? We chose because we wanted replicated ticket registries. That does seem preferable, barring any negatives that might outweigh the increased fault tolerance. Our implementation will be self-contained to our datacenter/dmz so we are not concerned with securing the replication traffic. Two of the nodes will be in our local data center, but we also plan to have a third at our DR site on the other side of the state. In general, even though our local network can for the most part be trusted, I try not to have sensitive data flow across it unencrypted. I ended up configuring ssh port forwarding tunnels to secure the data flow for the ehcache replication. Seems to working reasonably well, although RMI is a pain and you have to tell java it's running on "localhost" so it doesn't tell the remote client to connect to it directly rather than through the tunnel. I've also been unable to get the local RMI listening ports to bind to loopback rather than wildcard, ideally you would only be able to connect to them from the local machine. We do have a host-based firewall preventing access, but still, ideally :). It looks like that might only be possible with custom coding. Replication traffic isn't a particular issue for us. Us either, our local nodes will either be gigabit connected, or in our vmware cluster connected with virtual 10G, and our remote DR node will be at our sister campus Sacramento State. Both of us have 10G connections to the CENIC backbone network most educational sites in California use, so I don't think the remote traffic will have any problems either. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/7/2013 11:59 AM, Scott Battaglia wrote: You do realize you will have to configure and tune any solution :-) Well, yah :). Before comparing solutions, I would recommend defining your requirements and your tolerance for failure (if you have not). For example, Is it acceptable that if a node (that has > 99.9% uptime) goes down, a user must re-authenticate? Is that extra .1 worth whatever the cost? I can't answer that for you. I can't answer that for *myself* yet, as I lack sufficient information to do so. Both ehcache and memcached are open source with no direct cost, so the cost will be any additional CPU or bandwidth requirements for one versus the other, or any additional time requirements for implementation. At this point, I am prototyping ehcache, as I don't think the potentially greater bandwidth will be an issue for us. If the complexity, difficulty, or reliability of ehcache becomes an issue, then I'll consider falling back to memcached as an alternative. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] fault-tolerant/redundant/HA CAS deployment
On 8/7/2013 12:18 PM, Aaron Bennett wrote: What we're planning for scheduled maintenance, is using memcached-tool to push a given server's cache to another server before shutting it down for maintenance... something as simple as this.. ./memcached-tool localhost dump | nc 11211 My (limited and possibly inaccurate) understanding of memcached, specifically the client implementation for CAS, is that a particular key is hashed, and based on the outcome of that, the client looks for it on a specific node. So I'm not sure what good a copy of the data on another node will do if the client doesn't know to look for it there? Do you specifically pick the other node to transfer it to based on calculating what the backup node hash would be for the failed node? And in a failure mode, does the client actually try to do an initial read from the backup node, or just write out new data to it? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] Re: [cas-user] Re: [cas-user] Show of hands – clustering? Which backend?
On 8/7/2013 12:25 PM, Tom Poage wrote: Ehcache over RMI w/ automatic peer discovery. Thanks for the info; more detail in a previous reply, but would you mind sharing your ticket registry and ehcache configuration? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Show of hands – clustering? Which backend?
On 8/8/2013 6:10 AM, Marvin S. Addison wrote: http://jasig.github.io/cas/planning/High-Availability-Guide.html Thanks for providing this documentation; it's a bit more up to date and more understandable than the actual official wiki :). Maybe it could be integrated into the official site as to be easier to find… Memcached, no repcache. I went to a fair bit of trouble to justify why memcached alone is sufficient for most HA setups. Please read the following documentation, particularly the "High Availability Considerations" section: I do see that memcached can be "good enough". However, abstractly, it seems ehcache is "better", at least in terms of fault tolerance. What I'd be more interested in reading would be an enumeration of negativities or downsides of ehcache that outweigh its increased resilience :). So far the only one I've really seen is increased bandwidth utilization. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] RE: [cas-user] Show of hands - clustering? Which backend?
On 8/8/2013 7:29 AM, Carlos Fernandez wrote: We're using Ehcache with manual peer configuration and disk persistence. So far it seems the unofficial poll shows a higher percentage of ehcache versus memcached deployments. At the risk of becoming repetitive :), would you mind sharing your ticket registry and ehcache configs? Previously we used JPA for the ticket and service registry, but a massive dump taken by the database server cured us of that. Yes, it seems using JPA just moves your fault tolerance problem from CAS to the database server... We also use Tomcat session replication even though our load balancer does session persistence, since it was easy to configure and doesn't add to the load. I was initially going to set that up, but once it became clear that only covered a fairly tiny failure window, given I'm tunneling the replication traffic it didn't seem worth the extra effort. Thanks much… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] Re: [cas-user] Re: [cas-user] Re: [cas-user] RE: [cas-user] Show of hands – clustering? Which backend?
On 8/8/2013 11:52 AM, Tom Poage wrote: I tripped on that one--the TGT config is not inheriting from the abstract definition. I added a 'parent': Cool, thanks for the tip. Would you mind sharing the rest of your configuration so I can see if you fixed anything else I have broken :)? Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] size of TGT and service tickets in cache
Does anybody have a rough estimate of the approximate size of tickets in ehcache once they've been serialized and stored? I'd like to roughly correlate the number of tickets allowed in the cache with memory usage and vice versa. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] caching attributes?
So I'm trying to get CAS to retrieve attribute from LDAP, and ideally cache them to decrease load. I'm looking at: https://wiki.jasig.org/display/PDM15/Attribute+Caching and trying to figure out how to set the size of the cache and the TTL. It seems I need to use the userInfoCache property to tell it what cache to use. I've found some examples that use org.jasig.portal.utils.cache.MapCacheFactoryBean for this, which has a property "cacheFactory", but I haven't found any examples for that definition. Am I missing some obvious documentation somewhere? My google-fu is failing me, I've been flailing at this for a couple of hours and really made no headway on understanding how to configure this caching. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] group membership attribute
I'd like to include group membership as one of the attributes in our CAS deployment. However, we don't currently implement the memberOf attribute in our LDAP deployment, to get a users groups, you need to query on memberUid= and enumerate the groups returned. I thought I had worked out a way to do it within the persondir framework: This does work, to a degree; a memberOf attribute is added to the user, but only a single one, for the first group returned by the query. Is there any way to get this to populate attributes based on all of the results of the query, rather than just the first one? Or perhaps a better more recommended way to add a group membership attribute from an LDAP directory without the memberOf attribute populated for the user object? Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] group membership attribute
On Fri, Sep 13, 2013 at 01:14:38PM -0700, Paul B. Henson wrote: > This does work, to a degree; a memberOf attribute is added to the user, > but only a single one, for the first group returned by the query. Hmm, seems I'm not the first one to think of this: https://issues.jasig.org/browse/PERSONDIR-65 Unfortunately, this ticket from 2011 is still unresolved :(. I guess I need to either look into implementing the openldap memberOf overlay or try out the MergingLdapPersonAttributeDao class attached to the ticket. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] caching attributes?
On 9/13/2013 6:25 AM, Marvin S. Addison wrote: I would exercise caution with this approach. CAS natively employs attribute caching; attributes are only fetched on user authentication, so attributes are naturally cached for the duration of the SSO session. Ah, I did not realize that the attributes were cached with the TGT. That does indeed make caching attributes at the persondir level much less necessary. In most cases that's at least once per day which is arguably too long for certain kinds of authorization data. Yes, I'll have to mention this to our security group to take into account when deciding how long a TGT should last. It would be nice to have a feature that would not require the user to re-authenticate but would refresh their attributes more frequently (I'd probably go with hourly). That said, we use Ehcache in a custom attribute resolver to cache attributes during the authentication pipeline. I'm already using ehcache to replicate tickets between load balanced servers. While I might end up not implementing caching for the LDAP queries, could I trouble you to share your configuration if only so I can understand how it's supposed to work :)? I'm going to go on record and say I hate Person Directory. The only way I figure things out is by reviewing source: I can't say I'm very fond in general of the Java XML bean configuration methodology 8-/, it makes my head hurt :(. Thanks much for the information… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] caching attributes?
On Fri, Sep 13, 2013 at 01:16:30PM -0700, Marvin Addison wrote: > Here's the cache configuration we use for our custom resolver: > >class="org.springframework.cache.ehcache.EhCacheFactoryBean" > p:cacheName="PrincipalCache" > p:eternal="false" > p:overflowToDisk="false" > p:maxElementsInMemory="100" > p:timeToLive="5" > p:timeToIdle="5"> > >class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" > /> > > Cool, thanks. So to integrate that into the cachingPersonAttributeDao config, you'd just set the userInfoCache property to "principalCache"? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] caching attributes?
On Fri, Sep 13, 2013 at 01:44:43PM -0700, Marvin S. Addison wrote: > > So to integrate that into the cachingPersonAttributeDao > > config, you'd just set the userInfoCache property to "principalCache"? > > I'm not certain since I've never used that component, but it certainly > sounds like it would work. Seems easy enough to try. How are you integrating the cache into persondir if you're not using the persondir cache object? Are you inserting the cache somewhere in the ldap lookup pipeline instead so the LdapPersonAttributeDao object thinks it's doing an ldap lookup but hits the cache instead? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] caching attributes?
> From: Marvin Addison [mailto:marvin.addi...@gmail.com] > > We developed a custom resolver to meet our needs. I believe it uses > PersonDirectory under the hood but the details are not based on any > existing PD component. Ah, gotcha. Thanks for the info... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] caching attributes?
> From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] > > So to integrate that into the cachingPersonAttributeDao > > config, you'd just set the userInfoCache property to "principalCache"? > > I'm not certain since I've never used that component, but it certainly > sounds like it would work. Seems easy enough to try. Hmm, trying to do that resulted in a failure: java.lang.ClassNotFoundException: org.springmodules.cache.key.CacheKeyGenerator So I added spring-modules-cache to my maven dependencies and tried to rebuild, which failed: [WARNING] The POM for gigaspaces:gigaspaces-ce:jar:5.1-1603-000 is missing, no dependency information available [WARNING] The POM for jini:jsk-lib:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:jsk-platform:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:mahalo:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:reggie:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:start:jar:2.1 is missing, no dependency information available [WARNING] The POM for jini:boot:jar:20060125 is missing, no dependency information available [WARNING] The POM for jini:webster:jar:20060125 is missing, no dependency information available [WARNING] The POM for jboss:jboss-cache:jar:1.2.4 is missing, no dependency information available [WARNING] The POM for jboss:jboss-common:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jboss:jboss-jmx:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jboss:jboss-minimal:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jboss:jboss-system:jar:4.0.3 is missing, no dependency information available [WARNING] The POM for jcs:jcs:jar:1.2.6.5 is missing, no dependency information available [WARNING] The POM for xpp3:xpp3_min:jar:1.1.3.4.I is missing, no dependency information available Per this fairly old mailing list posting, it seems spring-modules-cache is less than intelligent about dependencies: http://forum.spring.io/forum/attic/spring-modules/21843-spring-modules-cache-dependencies Evidently Spring Modules have been deprecated by Spring Extensions as well. This is really more of a persondirectory issue than a CAS issue, so I thought I'd try their mailing list, but the user list mentioned at: http://www.jasig.org/mailing-lists/person-directory simply no longer exists, and the developer list has not had a message posted since 2012 8-/. And the last commit to the github repo is from early January: https://github.com/Jasig/person-directory Is this project still under development? In any case, I've wasted way too much time trying to figure out how this caching is supposed to work. I guess if we have a load issue in the future I'll just drop in more LDAP servers . -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] caching attributes?
> From: Scott Battaglia [mailto:scott.battag...@gmail.com] > > I can't promise anything but I'll see if we can easily convert persondirectory > to use Spring 3's cache apis. If that will make it any easier to actually use, that would be much appreciated :). It would be nice if the documentation could also include a couple of examples of working configurations, perhaps it's just my lack of java background but it's a bit mystifying how to get all the pieces to work together. Thanks much... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] mod_auth_cas release?
It looks like the last mod_auth_cas release (1.0.9.1) is over three years old. Reviewing the changes since then, there are at least a few I think I'd like to have. Are there any plans to cut a new release, or is mod_auth_cas switching to the "just use the latest git checkout" philosophy some projects have started advocating? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] mod_auth_cas release?
On Tue, Oct 01, 2013 at 02:12:42PM -0700, Misagh Moayyed wrote: >I would definitely welcome a binary release. The build process can be a >bit tedious and long, specially to prepare the environment. >Sounds like we might need a decent CI tool to at least publish >snapshots somewhere. Bamboo? Travis? I don't really care about a binary release, just a stable version of the source so distributions can update their packages and so people compiling it themselves aren't using dozens of different "versions of the day" as is prevalent in some projects which don't release... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] caching attributes?
> From: Scott Battaglia [mailto:scott.battag...@gmail.com] > Sent: Tuesday, October 01, 2013 7:58 PM > > I looked at migrating to Spring 3's caching APIs and its more effort than I > expected it to be. I'll have to defer it for now. Our applications group contracted Unicon to help them out with uPortal deployment, I spent a little time today with them discussing our CAS implementation. I've actually got two issues with CAS and attribute caching - this issue, that I can't really see a clean way to implement persondir attribute caching within a CAS context, and then that CAS itself caches attributes too long, I think there should be a way to have attributes refreshed more often than you might want to have the lifetime of the TGT. We came to the conclusion that potentially the best approach moving forward would be to have CAS stop storing attributes with the TGT, but instead do a fresh lookup of them for every service ticket granted, along with fixing persondir caching to work better with CAS. This would allow you to separate your session timeouts for TGT's from attribute cache timeouts, the former configured within CAS and the latter based on your persondir cache configuration. Unicon said this is something they could potentially work on for us and contribute back to CAS/persondir. I'm not sure how much effort it would actually require; our applications group tends to have a fairly large budget for consulting, so I'm hoping I might be able to shoehorn this CAS enhancement into their uPortal deployment budget ;)... Plus, they had actually budgeted for Unicon to configure/deploy CAS for them, and I kind of already went and did that, so at the very least that chunk of change should be available... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] multi valued attributes in CAS 2.0 protocol
I modified CAS per the wiki: https://wiki.jasig.org/display/CASUM/Attributes to deliver attributes using the CAS 2.0 protocol. One of these is a multivalued attribute, and I was having a problem getting it to work with an application that I initially blamed on the application, but on further investigation: henson [eoc_essential, employee, member, staff] It looks like CAS is sending a multivalued attribute as a single xml value consisting of the individual values separated by commas wrapped inside of square brackets? I found one link that seems to indicate this is expected behavior: https://www.purdue.edu/apps/account/docs/CAS/CAS_java_client.jsp But reviewing the source code for the official PHP CAS client, it seems to expect multivalued attributes to be encoded in XML in the more usual way of actually having multiple XML entries: eoc_essential employee member staff What is the "unofficial official" way of handling attributes in the CAS 2.0 protocol? Should I complain to the application vendor that they are not doing the right thing, or do I need some different modification to casServiceValidationSuccess.jsp other than the one listed on the wiki that will encode the attributes in a different way? Thanks much... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] > Sent: Thursday, October 10, 2013 6:18 AM > > I honestly don't know. The official mechanism for attribute release is > via the SAML 1.1 protocol. Attribute release will be officially > supported in the CAS 3.0 protocol spec: My understanding was that despite it being the "official" mechanism, SAML is for the most part deprecated, and most people are extending the CAS 2.0 protocol to supply attributes rather than using SAML. I'd like to get the server to do what the average client is going to want :)... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: Tom Poage [mailto:tfpo...@ucdavis.edu]
> Sent: Thursday, October 10, 2013 8:30 AM
>
> The attribute string "[ foo, bar, baz ]" looks suspiciously like the result
> of a
> toString() on a collection.
The jsp code on the wiki:
${fn:escapeXml(attr.value)}
does look like it pretty much spits out value, I'm not
that familiar with jsp, is it likely that attr.value is a collection, being
converted to a string? In which case perhaps the jsp could be modified to
detect that it is a collection and do another foreach to split it up and write
out each value separately rather than concatenated? Or is it more likely that
attr.value is already a flattened out string when it is referenced in the jsp?
> Both flavors of SAML represent attributes as roughly:
Well, in this case that only matters if the average CAS 2.0 attribute extended
client likes them that way :). Looking at the php CAS client, it accepts a
variety of different attribute encodings, none of which seem to match the
example on the wiki as far as how to enable it on the server-side 8-/...
Thanks...
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: Marvin S. Addison [mailto:marvin.addi...@gmail.com] > Sent: Friday, October 11, 2013 6:35 AM > > Absolutely not. It may be deprecated at some (distant) future date, but > many folks are happily using the SAML support in many clients for > attribute release. No server or client customizations needed. Hmm, that's the impression I got after a meeting with Unicon, perhaps I misunderstood them. In any case, it looks like the client I'm trying to get to work (ezproxy) doesn't support SAML :(, so I'm stuck with unofficial CAS 2.0 attributes. Did you by any chance have the opportunity to look at the other email I sent on this subject as far as whether or not the variable within the jsp file has already been flattened, or if there is the potential to tweak the jsp to iterate over it and generate separate entries for each value rather than flatten it? Thanks much... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: Marvin S. Addison [mailto:marvin.addi...@gmail.com]
> Sent: Friday, October 11, 2013 11:08 AM
>
> You mean this:
>
>
>[a, b,
> c]
>
No, I meant the post containing the underlying jsp code that generated it:
${fn:escapeXml(attr.value)}
This code does appear to generate one entry for each attribute, containing
whatever attr.value is. My curiosity is whether the attr.value variable is a
collection at this point in the jsp, and the escapeXml call is what is
flattening it (in which case the jsp could potentially be modified to detect it
is a collection and do an additional foreach to break them out separately) or
if the variable attr.value is already flattened by the time the jsp sees it, in
which case it would need to be fixed somewhere else.
> I admit that doesn't look correct but I'm not certain. What reference
> did you follow for customizing the casServiceValidationSuccess.jsp file?
I copied it from the wiki:
https://wiki.jasig.org/display/CASUM/Attributes
Thanks...
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] > Sent: Friday, October 11, 2013 11:51 AM > > Since you brought up the Unicon meeting I figure I'll just respond > here in this thread. Sorry if I gave you the wrong impression > regarding the official status of /cas/samlValidate. Possibly I misunderstood you; the question was more or less whether most applications would do samlValidate and I didn't need to worry about the custom jsp extension, or if most applications only worked with CAS 2.0 attribute extensions, and the rough answer was more or less the latter. Which, at least in the case of ezproxy, seems to be true so far :). > This thread might be of some help with OCLC. > https://groups.google.com/forum/#!topic/jasig-cas-user/QsW2eeA6WYw Yeah, that looks like basically what I'm doing. The ezproxy client sees the attributes being returned by the custom jsp with no problem, it's just that multi valued attributes are getting flattened out into a single value which is less than ideal. And that's definitely on the CAS side, not the ezproxy side, as can be seen in the returned XML. Thanks... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: Marvin Addison [mailto:marvin.addi...@gmail.com] > Sent: Friday, October 11, 2013 1:40 PM > > Missed that. That JSP code absolutely will not work with the attribute > parsing code in phpCAS HEAD revision. Here's the source for the That's an annoying inconsistency, given that piece of the wiki describing the jsp modification is entitled "Accessing attributes using phpCAS" ;). > I think the comment makes it pretty clear the expected XML format, > which matches my recollection. You'll need an inner loop to unroll > attribute values that contain collections. It sounds like the jsp has access to the un-flattened collection then, so I guess if nobody on the list who writes jsp in their sleep steps up, I'll go hack at it... Thanks... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: William G. Thompson, Jr. [mailto:wgt...@gmail.com]
> Sent: Friday, October 11, 2013 5:36 PM
>
> You'll want to take a look at this: https://issues.jasig.org/browse/CAS-1283
That code looks suspiciously similar to the code on the wiki; I don't really
see how that would not also flatten out multivalued attributes into a comma
separated list as opposed to enumerating them separately?
I guess the jsp foreach is smart enough to do the right thing if you give it
just a simple string rather than a collection, as:
${fn:escapeXml(attrval)}
seems to do what I want:
henson
Henson
Paul
eoc_essential
employee
member
staff
And yay, ezproxy successfully parses this...
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Integrate CAS with Openldap
On Fri, Oct 18, 2013 at 07:03:10AM -0700, Geo P.C. wrote: >We installed CAS Server 3.5.2 and configured https. Now we need to >integrate this CAS server with our openldap server. Please let us know >how we can integrate with it. We refereed this url: Integrate how? As an authentication source? Or as an attribute source? Or both? >From the authentication perspective, I just added this bean to the top of deployerConfigContext.xml: and updated the authenticationManager bean authenticationHandlers to include: If you can't staticly determine the DN of your users from just the username, you won't be able to use the FastBindLdapAuthenticationHandler, you'll need to use the one that searches for a user to find the DN before binding. You'll also need to pull in the cas-server-support-ldap dependency. The only really clean way to do this it seems is via the maven overlay method: https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method The documentation isn't quite there, so it might take a few rounds before you get it all sorted out. If I get some time, I'll try to go back through my recent install and make note of all the things the wiki was missing or had outdated information on and do some updating... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Integrate CAS with Openldap
On Mon, Oct 21, 2013 at 05:15:22AM -0700, Geo P.C. wrote: >Than you very much for your reply. I configured as you said and now CAS >is authenticating with LDAP but after login we are getting as "CAS is >Unavailable.There was an error trying to complete your request. Please >notify your support desk or try again." It looks like you updated the credentialsToPrincipalResolvers to include the CredentialsToLDAPAttributePrincipalResolver bean? I believe that is no longer required for the current version of CAS, you must have picked it up from obsolete documentation. > [...] > class="org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver"> I didn't change that section at all on my setup. Try putting it back to what the default config contains... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] multi valued attributes in CAS 2.0 protocol
> From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] > Sent: Tuesday, October 22, 2013 9:18 AM > > Sorry I was clearer...the pointer to CAS-1283 was a more of a > suggestion to engage on that ticket...presumably to incorporate your > enhancements. Ah, okay; I updated the ticket with a comment indicating it currently does not handle multivalued attributes and included the sample code adding an additional loop to avoid flattening them out. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Demo CAS Protocol Support in Shib IdPv3
> From: Marvin Addison [mailto:marvin.addi...@gmail.com] > Sent: Friday, November 08, 2013 7:07 AM > > I have a working demo that showcases basic CAS protocol v2 support in > the Shib IdPv3. Hmm, interesting; is this just an exercise in seeing whether or not it could be done, or are there plans to make it so functional as to negate the need to run a separate CAS server if you already have shibboleth deployed? -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] shib-cas-authenticator
We are looking at using unicon's shib-cas-authenticator package to integrate our existing shibboleth deployment into our new CAS deployment. Reviewing the documentation at: https://github.com/Unicon/shib-cas-authenticator it seems it wants to embed configuration into the WAR file. I've never really understood the fascination in the Java community with embedding configuration into binaries 8-/, it makes it rather difficult to package and deploy at scale :(. I have production, dev, and test CAS servers, as well as corresponding shibboleth servers, and I'd really like to build *one* WAR file to deploy on all of them, and have the specifics of the configuration maintained in external configuration files. Is there any easy way to externalize the configuration the documentation says to embed in cas-authentication-facade/src/main/webapp/WEB-INF/web.xml and $CATALINA_HOME/webapps/idp/WEB-INF/web.xml? One thing that's nice about shibboleth is that the default configuration does externalize configuration into the filesystem rather than try to embed it in the WAR file... Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] shib-cas-authenticator
> From: Dan Webb [mailto:d.w...@derby.ac.uk] > Sent: Wednesday, January 22, 2014 12:21 AM > > Yeah we're having the same problem here with dev and production using the > same war. Using two different wars would easily lead to configuration drift. Typically in an enterprise deployment, you have a package management system, and a configuration management system. With almost everything else I work with, I can easily create a binary package of an application, which can then be automatically installed anywhere it needs to be, and configure it as necessary automatically through our configuration management system. But anytime I have to touch anything involving enterprise JavaBeans, it seems to involve bending over backwards and jumping through hoops to try to avoid having to compile a specific binary for each and every single system on which it needs to be deployed :(. For our CAS servers I ended up having to have a custom post install for the package that swaps out config files in the WAR with ones from the file system before copying it into the webapps directory . Maybe I'll have to do the same thing here. It would make things so much easier if the WAR file simply referenced an external configuration file... I'm sure I'm not exactly winning friends and influencing people with Java rants in what's likely a Java friendly forum ;), but as long as I've got my grumpy old man hat on, what's with all the different build utilities? This one uses ant, that one uses maven, hey, look, gradle! On top of trying to fit a square self-contained java app peg into my round enterprise systems management hole, I've got to set up and figure out a completely new build environment every time... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] shib-cas-authenticator
> From: Tom Poage [mailto:tfpo...@ucdavis.edu]
> Sent: Wednesday, January 22, 2014 1:17 PM
>
> Maybe not the prettiest/correct/... way, but one thing we did was to
> allow overriding Spring configuration in the file system, using a
> parallel directory structure analogous to that in the war, and setting a
Hmm, that looks promising, the three files I am overriding are
WEB-INF/spring-configuration/propertyFileConfigurer.xml
WEB-INF/spring-configuration/ticketRegistry.xml
WEB-INF/deployerConfigContext.xml
So what would happen if you put a copy of deployerConfigContext.xml in
:${cas.home:/etc/cas}/spring-configuration/? Or added
:${cas.home:/etc/cas}/spring-configuration/deployerConfigContext.xml to the
param list? Could you use an external file system source to override that too?
Thanks for the tip...
> >
> > contextConfigLocation
> >
> > /WEB-INF/spring-configuration/*.xml
> > /WEB-INF/deployerConfigContext.xml
> :${cas.home:/etc/cas}/spring-configuration/spring-configuration/*.xml
> >
> >
>
> Then ${cas.home} contains e.g. directories 'classes' and
> 'spring-configuration' (my understanding with Spring is "last one wins").
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] Hazelcast ticketRegistry
Has anybody tried out Unicon's relatively new Hazelcast ticketRegistry backend available in their cas-addons package? It looks very promising and should be more scalable and higher performance than ehcache (which we are currently using) particularly when you are using secure point-to-point links rather than multicast for communication. I've started playing with it in our dev environment and would be interested in feedback from anyone who might have deployed it already, or would be interested in discussing configuration tuning... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] LDAP: Bind vs FastBind
On Fri, Feb 21, 2014 at 12:14:17PM -0800, Tom Poage wrote: > The username/principal is exposed through service ticket validation as > entered at the login page, so if the client enters "Fred" one time and > "FRED" another, it'll match the same LDAP entry, but to any > case-sensitive app downstream, it looks like two different clients. > > Ended up implementing a CredentialsToPrincipalResolver: We kludged it and just tweaked the CAS login page to lowercase the username before submitting it :). Should catch 99% or more of the problems... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] LDAP: Bind vs FastBind
On Sat, Feb 22, 2014 at 05:07:29AM -0800, Marvin Addison wrote: > We should probably support this via configuration in the components we > ship. There's a slot for hooking an arbitrary transformation on > username prior to authentication [1], but I don't believe we ship a > component that does case transformation. Seems a lowercase transformer > would solve 99% of use cases. Please file a Jira if you're in > agreement. CAS-1430, thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] ehcache replication - resources question?
> From: Aaron Grant > Sent: Friday, March 14, 2014 6:03 AM > > We were considering replicating our CAS tickets using ehCache and were > wondering how many other folks did this and did you see a considerable > jump in your memory or cpu usage on your CAS servers? We originally deployed a two node cluster using ehCache; it mostly works but I wasn't particularly happy with it. If you are using unicast, as opposed to multicast, there is an as yet unfixed bug that severely impacts scalability, it reduces performance in a two node cluster and renders a three node cluster simply intractable. I recently tried out Unicon's relatively new hazelcast ticketRegistry, it's a lot simpler to configure compared to ehCache and works a lot better. https://github.com/Unicon/cas-addons/wiki/Configuring-HazelcastTicketRegistry I'm planning to swap out our existing two node ehCache cluster in a couple of weeks with a three node hazelcast cluster. I don't like to pass credentials in plaintext over the wire, as ehCache didn't support any type of encryption, I ended up tunneling its traffic with ssh. Hazelcast supports two different modes of encryption, SSL and symmetric, but unfortunately neither of them seem reliable under load. For my new cluster, I ended up setting up ipsec tunnels between the nodes and leaving the encryption to the OS rather than the replication library, that turned out to work very well. If you are just starting, personally I would recommend trying out hazelcast before ehCache. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] annoying responses
Every time I send a message to this list, I get dozens upon dozens of automated responses from vacation messages and out of office responders. This is almost the only list for which that happens. Is there some configuration that could be set to make this stop? It is extremely annoying. I see some lists set the header X-Auto-Response-Suppress: All, whereas others have Precedence: bulk, or some other mechanism to inform auto responders not to respond. Nothing like that is available for this list? Ironically, my first submission of this message had a subject that included the words out, of, and office, and it was rejected by the list management software 8-/. However, the auto responses I'm talking about come directly to me, not to the list. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] annoying responses
On Sun, Mar 16, 2014 at 10:22:43AM -0700, Marvin Addison wrote: > > Is there some configuration that could be set to make this stop? > > Not for messages sent to your directly for what are hopefully obvious > reasons. I have gmail filters to delete them. For a couple years I > attempted to politely contact these people to let them know; of many > handfuls of emails written I think I got a couple "Oh, thanks for > letting me know." Clearly it was a waste of time. Yeah, some people are oblivious . But this is the only list I'm subscribed to from which I receive such a barrage of autoresponses, and I can't imagine there are no oblivious people on the numerous other lists I'm a member of. There's no option with whatever list software in use to add a Precedence header or other indicator for autoresponders to key off of? Almost all my other lists have such headers, and I rarely receive autoresponse bombs from them. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] annoying responses
> From: Misagh Moayyed > Sent: Monday, March 17, 2014 1:00 AM > > Marvin, could you plz share your filtering rules? I am looking at the list > admin interface and I see we have an option to setup "match phrases" to > reject messages. We could do this for all 3 of the cas lists. That might help; however, most of the objectionable "not available" messages I see come directly to me, not through the list. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] annoying responses
> From: Marvin Addison > Sent: Monday, March 17, 2014 2:33 AM > > I'll forward the suggestion to the mailing list admins at UW Madison > for consideration. Takes a few days to get to the right person but > I'll follow up when I get a response. Great, thanks. Obviously it's no big thing in the overall scheme of things, but every little bit helps :). -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Richard Frovarp > Sent: Monday, March 17, 2014 9:24 AM > > You probably want the logout of a single system to log the user out of CAS. > Otherwise you could have surprising SSO's happen. I dunno, it seems it would kind of defeat the purpose of "single sign-on", if every time you stop using a single application you've got to sign on again to use a different one... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Curtis Long [mailto:curtis.l...@dc-uoit.ca] > Sent: Monday, March 17, 2014 9:49 AM > > We considered not having Bb sign users out of CAS, but I don't think that it > is > intuitive if you have a large loosely connected applications like Bb. For > example, a student logs out of Bb, and then types the URL to go back to the > app directly (say a friend wants to login). Since the CAS session would > still be > there, they would be automatically logged in as though they had never > clicked 'Log Out' with the same user? May make sense if you have tighter > integration going on, or good communication about closing browsers and > cookie security, but something to consider. Don't almost all web apps say something along the lines of "you have been logged out of your session, please close your browser to complete the log out and maintain security"? Ideally each application session logout page could be updated with a note describing that a single sign-on session is still in force and provide a separate link to log out of CAS if so desired. I think it pretty much breaks SSO if any application you stop using destroys your central SSO session. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Richard Frovarp > Sent: Monday, March 17, 2014 2:19 PM > > But it isn't stop using an application (unless a timeout there forces a > logout of CAS). It's actually logging out of the application, and the > user desiring to remove their access to the system. What good is logging > out of an application if the only step required to get back in is > clicking the login button? Consider two scenarios: 1) You have a single sign-on session, access blackboard, and then log out of blackboard, but retain your single sign-on session. You then click back to blackboard, and are transparently logged back in. 2) You have a single sign-on session, but gained from accessing some other application, you have had absolutely no interaction with blackboard at all. You click on a blackboard link, and are transparently logged in. Is #1 surprising, but #2 is not? They are both inherent artifacts of having a valid single sign-on session. > A surprising SSO is you logging out of a website, me sitting down, > clicking login, and then being you. That isn't the point of SSO. There are really two ways to look at "SSO". The first is that you simply use the same username/password pair for every single service, even if you have to authenticate separately to them. The second is that you authenticate once, and then can access every service without authenticating again. Which one are you trying to implement? Because if you are trying to implement the latter, then having an application "logout" destroy your single sign-on session is what would be surprising. Basically, in the context of a global single sign-on session providing access to all applications, the concept of "logging out" of a particular application is no longer valid. Either you are "logged in" to everything, or you are "logged out" of everything. And it seems the proper solution isn't to have any single application destroy the entire session, but rather stop having "application" logouts, and instead have each individual application logout page go to a central CAS page where a user can select to destroy their session or not. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Richard Frovarp > Sent: Monday, March 17, 2014 5:36 PM > > Imagine this scenario. You are logged into Blackboard, you click logout. You > get up, another person sits down at that same machine with the same > browser session. I'm not familiar with the specifics of the blackboard "logout" page, but almost every single web app I've ever used, when you click on the logout button, takes you to a page saying you are logged out and that you should close your web browser for security purposes, or to clear your session, or for whatever. If the blackboard page says something like that, and the user did not close the web browser, then I guess they got what they deserved. If the blackboard page does not say something like that, then it should, as regardless of the state of CAS there is potentially sensitive data in the cache or cookie store that might be accessible before the browser is closed. > There is SINGLE sign on (SSO) and SAME sign on. The second is same sign on. Wikipedia disagrees with you: http://en.wikipedia.org/wiki/Single_sign-on "Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them." As does the open group, although their relevance nowadays might be questionable: http://www.opengroup.org/security/sso/ "Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords." I'd never heard of "Same Sign-On" before, from the few Google hits that result from searching for it it appears to be some terminology Microsoft made up. They seem to like co-opting acronyms, I remember when we were running DCE/DFS and they introduced their "Dfs" product... > The idea is to implement the system to fit the needs of your institution. > Single sign off is certainly not one of them for us, and I suspect that many > other schools would find the same, especially if session timeouts are going > to trigger them. We have single sign off disabled as well, that's actually recommendation in the default CAS config. I agree in any case that this is a bit of a complicated subject, and the intersection of the technology with the usual caveats of training users is going to be a bit of a mess . -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Richard Frovarp > Sent: Monday, March 17, 2014 5:46 PM > > One other thought. Your proposed method may end up essentially being a > "Do you really want to logout?" sort of system. If the typical workflow for > most of the users is to be logged into one application, then logout and be > done, it becomes are "Do you really want to logout?" type system. If they > are typically logged into multiple CAS based services at a time, then it has > the > flavor you are after. It really comes down to the average workflow of your > users. The powers that be here are planning to deploy uPortal, and pretty much make every other service subservient to it, whether through portlets or by only putting the link to the service on uPortal. So I think at least at our site you will be guaranteed to be logged into at least two applications, uPortal and what ever you actually wanted to use... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Richard Frovarp > Sent: Tuesday, March 18, 2014 2:41 PM > > That's not necessarily disagreeing with me. That's describing true SSO, > because user's aren't prompted. [...] > theirs, as it makes the most sense to me. If you use the same > credentials to login to two completely different places (and the same > credentials are by design), I call that same sign on. I steadfastly > refuse to use the SSO acronym or single sign on term for any system that > asks for credentials again. It seems we had a communications breakdown, as I said: "There are really two ways to look at "SSO". The first is that you simply use the same username/password pair for every single service, even if you have to authenticate separately to them. The second is that you authenticate once, and then can access every service without authenticating again." You then said: "There is SINGLE sign on (SSO) and SAME sign on. The second is same sign on." However, in my description, the "second" was the one where you authenticate once, and then not again. So it sounds like we agree on SSO, but simply failed to successfully negotiate the description ;). -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] ehcache replication - resources question?
> From: Scott Massari > Sent: Wednesday, March 19, 2014 8:49 AM > > What bug are you referring to? https://jira.terracotta.org/jira/browse/EHC-640 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Blackboard Integration
> From: Rex Roof > Sent: Wednesday, March 19, 2014 7:31 AM > > this points out a very frustrating issue with blackboard's default CAS > implementation: > you either 1) get SSO but are forced to do cas logout, > or 2) you aren't forced to do cas logout but the user has to type their > password when they use CAS to access blackboard. I'm sure anybody who's ever actually used blackboard is quite used to being frustrated 8-/. Our blackboard admin forwarded me a thread from the blackboard administrators mailing list about this. Evidently somebody asked blackboard to fix it, so you could change those two settings independently, and they said the customization fees blackboard wanted were prohibitively expensive. Seriously? Update the GUI not to grey out one checkbox when the other one isn't selected? Blackboard sucks. I wish we would switch to Moodle... -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] annoying responses
On Fri, Mar 21, 2014 at 09:14:01AM -0700, Marvin Addison wrote: > The header "X-Auto-Response-Suppress: All" has been added to each of > the lists. Let me know how this works for you and we can make changes > to other lists as you see fit. "has" or "will be"? I don't see it on any of the messages posted today. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] annoying responses
0, __RDNS_GMAIL 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __YOUTUBE_RCVD 0 x-origin: Off x-received: by 10.180.163.206 with SMTP id yk14mr4466448wib.5.1395429117315; Fri, 21 Mar 2014 12:11:57 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] annoying responses
> From: Paul B. Henson > Sent: Monday, March 24, 2014 2:35 PM > >-Auto-Response-Suppress as opposed to Precedence? I know the latter > doesn't get discarded. I'd be curious if other people who are either > stuck using exchange or have an Ironport mail appliance are also losing > this header, if a sizable fraction of users don't get the header passed > through then their auto-responders will still misbehave... Huh, the only annoying auto response I got to this message was an exchange out of office message from a colleague who also works here 8-/. Maybe I will go bug our ironport and exchange administrators as to why one of those is eating this header . -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS + Shibboleth Integration Best Practices
On Mon, May 05, 2014 at 06:33:32AM -0700, Ben Branch wrote: >I currently have about 3 projects that may require us to implement some >form of CAS+Shibboleth integration. We've been running shibboleth for years, and recently deployed CAS. Our management decided they want to use CAS as the authoritative authentication system on campus, so we configured our existing shibboleth deployment to delegate authentication to CAS. Out of all the various options, at least for our purposes, the "Shibboleth IdP External Authentication via CAS plugin" framework from Unicon seemed to be the best: https://github.com/Unicon/shib-cas-authn2 This is an updated version of a previous implementation, it hasn't been out very long, but we're currently running it in production (the current 2.0 release has a couple minor bugs, so we're actually running 2.0.1-SNAPSHOT at commit 3e0fa2aebfe6ca9da430687caee0125636118bdf). So far we haven't had any issues with it. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Microsoft Dreamspark
On Tue, Jun 10, 2014 at 04:52:07PM -0700, Bryan E. Wooten wrote: >Has anyone integrated CAS with this? Do you mean the webstore hosted by Kivuto at onthehub.com? We used shibboleth for that, but currently delegate shib auth to CAS, so indirectly we have it integrated with CAS ;). -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS integration with Shibboleth IDP
> From: Ted Fisher > Sent: Thursday, August 07, 2014 12:03 PM > > No, I don't want to prompt the user at each auth attempt. Once they have > authenticated with CAS I only want the IDP to get a new ST at each auth, > which is what is not happening. I want the IDP to depend on CAS to What method are you using to integrate CAS and shibboleth? I am using unicon's shib-cas-authn2 implementation: https://github.com/Unicon/shib-cas-authn2 And it works exactly as it sounds like you want, every time shibboleth needs to authenticate it pokes CAS, which then either requires an authentication or if there is a valid TGT presented it issues a new ST with no authentication required. I assume you removed the PreviousSession login handler in the shibboleth handler.xml configuration? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] CAS ISAPI filter configuration
One of my colleagues has an application that runs under IIS that he would like to use central authentication for. Unfortunately, the company is not interested in integrating CAS support into their application. However, it does currently support delegating authentication to IIS and integrating into Windows domain authentication. Based on my limited understanding of that infrastructure, I thought we should be able to use the CAS ISAPI filter to make this application use CAS rather than Windows domain authentication (with a caveat; I assume the application is looking for the standard remote_user header, the application would need to either need to be modified to support looking for the authenticated username in a custom header, or we would need to binary edit it to change the header it currently looks for). He has it installed and mostly configured, but he is not sure what to set the "Service URL" to, and neither am I. In a CAS transaction, the service URL is where the CAS server sends a browser after it gives out a service ticket after successful authentication, and that URL is then responsible for consuming the service ticket, validating it with CAS, and then providing access to the underlying application. But given in this case the application has no idea it is using CAS, shouldn't the "Service URL" functionality be handled by the CAS ISAPI filter itself somehow? Or am I misunderstanding how the CAS ISAPI filter is supposed to work? Any hints on how to appropriately configure this would be much appreciated. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS ISAPI filter configuration
> From: John Gasper > Sent: Wednesday, September 10, 2014 8:39 AM > > (This is very much like how the .NET Client works). It could be that you can > set the service url to be whatever you want CAS Server to redirect the > browser back to. Ah, interesting; if that is the case, the documentation could stand to have a little more clarity :). I will have him give that a try and see what happens, thanks for the suggestion... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS ISAPI filter configuration
> From: Ourada, John > Sent: Wednesday, September 10, 2014 8:47 AM > > Beware of the CAS ISAPI filters that exist... They don't terminate headers > correctly and Chrome will complain and not continue. > > UC Davis had the best one out there (IMO), but aren't able to support it > anymore. Actually, version 2.2 was released on Nov 25, 2013, with a change list of "Chrome interoperability issue fixed". I'm not sure what their long-term plans are as for supporting it, but I believe they have fixed at least the issue with chrome. > If the IIS version is high enough (7 and 8, I believe), you can use the .net > CAS > client to perform the authentication. I did this on a test server and was in > the > process of convincing the vendor to try it, but they were able to switch to > use ezproxy. You can use the .net client without cooperation from the application actually being authenticated? > There is some documentation on jasig on how to make this work. What documentation are you referring to? The only documentation I see for the .net client says "The .NET CAS client integrates with ASP.NET applications by customizing the application web.config file" and "Ensure it is deployed to the /Bin directory of the Web application", both of which seem like things that would require the cooperation of the actual application, as opposed to the ISAPI filter, in which the authentication is completely handled by IIS itself? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS ISAPI filter configuration
> From: Ourada, John > Sent: Wednesday, September 10, 2014 1:17 PM > > Use this as a starting point: > https://wiki.jasig.org/pages/viewpage.action?pageId=35389878 Cool, thanks for the pointer. I will forward this to my colleague and see if it would work better for him than the ISAPI filter. Thanks much... > Don't worry about PHP or FastCGI. If you basically read through the > instructions, you end up with the server variables being passed to the > application. I had it working with a test version of a .net app that didn't > have > any setup with CAS. Unfortunately, I have taken down the system where I did > my testing. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] HA architectures for CAS
> From: Adam Causey > Sent: Wednesday, October 15, 2014 11:43 AM > > I am looking into the HazelcastRegistry. It seems fine so far in a test > environment, but I have not load tested it. A few others indicated they are > using it in a production environment. It's very easy to setup. I've been running a three node Hazelcast CAS cluster for about a year or so, it's been great (thanks unicon!). Performs well, and I've had no problems with it. The only caveat was that I was unable to get the bundled Hazelcast encryption working. I ended up using IPsec tunnels to route the cluster traffic to be secure on the wire, that worked out great, even better than the bundled Hazelcast encryption. If you don't care about the cluster traffic being secure on the wire it won't be an issue for you… -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] HA architectures for CAS
> From: Adam Causey > Sent: Wednesday, October 15, 2014 11:46 AM > > I should mention that my solution does not include replication for the > services registry, which is my next step. So I will be interested in what > works > for you. We use the unicon json services registry. The file is stored in our distributed configuration management system and automatically pushed out to all the boxes when it changes. The boxes are configured to reload it within 10 minutes or so I think. Trying to have some kind of clustered/replicated database backend for that seems a bit overkill. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE:[cas-user] CAS and BlackBoard
> From: Stephen Meier > Sent: Monday, December 15, 2014 1:41 PM > > Has anyone tried to setup BlackBoard to authenticate against CAS? I have > configured the CAS server settings in blackboard, however, when I click the > login link, the CAS server redirects to a blank page. Our blackboard administrator configured the native CAS client and it seems to be working okay. It does force you to choose between either ignoring an existing CAS session and always requiring a username/password when accessing blackboard, or accepting an existing CAS session without requiring reauthentication but destroying the session when you click the blackboard logout link 8-/. Seems kind of stupid. I don't really know the details, I could put you in touch with our blackboard administrator off-line if you would like. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: Jérôme LELEU > Sent: Thursday, January 22, 2015 6:49 AM > > Yes indeed, you should upgrade to close the vulnerability if you use LDAP > authentication. You know, if you're going to announce a "holy crap upgrade now" security issue, it would be nice to get a little advance notice that it's coming 8-/. I don't quite understand this vulnerability. According to the announcement (http://seclists.org/oss-sec/2015/q1/205), it says "CAS Server 3.5.2 allows remote attackers to bypass LDAP authentication via crafted wildcards". Then under the description it says "A valid username and password required." It further says "The login will be sucessfully only if the ldap bind search return one unique member." If you need to know a valid username and the correct password for that username, how exactly are you "bypassing" authentication? It sounds like if you specify a wildcard that matches one and exactly one identity in your directory, *and* you supply the correct password for that identity, you successfully authenticate? Again, I don't understand how that can be considered to bypass authentication? It looks like the only ramification is that you can successfully authenticate with a string that isn't exactly the username, and that string is then presumably provided to the application you are trying to authenticate to? So instead of the application thinking the user "henson" logged in, it would think the user "hens*" logged in? Presumably undesirable, with potentially unknown ramifications depending on the application, but still not bypassing authentication. Also, I can't seem to reproduce it on my deployment. The LDAP wildcard "henso*" matches one and exactly one entry in my directory. If I type "henso*" and my correct password into the CAS login form, it tells me it is invalid. If I try the example in the announcement: curl -k -L -d "username=henso%2A&password=X" https://auth.csupomona.edu/cas/v1/tickets All I get in return is the CAS login page. Is this vulnerability dependent on how you have LDAP configured? I am using the FastBindLdapAuthenticationHandler mechanism. I don't believe there is any way for this vulnerability to apply to my configuration, as attempting to directly bind with the provided wildcard will always fail. Perhaps the vulnerability is only applicable to people using the BindLdapAuthenticationHandler, which would perform a wildcard search and find an entry which it would then try to bind as? Please clarify the issues surrounding this vulnerability so users can respond appropriately. My initial impression is that if you are using the FastBindLdapAuthenticationHandler you are not affected, so perhaps instead of announcing "You must upgrade if you use LDAP authentication" you should announce "You should upgrade if you are using the BindLdapAuthenticationHandler for LDAP authentication"? I also don't think the CVE should have a title that it bypasses authentication, as you're hardly bypassing authentication if you are required to know the username and password for the account 8-/. More accurately, it seems you can simply misrepresent your username to an application. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS Client Proxy distributed cache size
> From: Adam Causey > Sent: Thursday, January 22, 2015 10:57 AM > > I am setting up a CAS proxy on a client that is clustered and am using the > ehcache clustering option to distribute the PGTs between nodes. Personally I would recommend the Hazelcast clustering option over the ehcache mechanism… Any particular reason you are going with ehcache? -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: Andrew Morgan > Sent: Thursday, January 22, 2015 12:42 PM > > You aren't effected when you use FastBindLdapAuthenticationHandler. Thanks for confirming my initial analysis. > It's hard to call this a vulnerability, which is probably why they didn't > release it as such. More like, "here's CAS v3.5.3 which fixes a security > related bug." Well, I woke up a bit late this morning and found an announcement in my inbox saying: "You must notice that there is a security fix for the "LDAP login with wilcards" attack (CVE-2015-1169). You must upgrade if you use LDAP authentication." That already has the buzzwords "security fix" and "must upgrade". Then I looked up the CVE, which includes the title "allows remote attackers to bypass LDAP authentication via crafted wildcards". How can anybody not reasonably interpret the two of those as "Oh shit my CAS servers are Swiss cheese and are going to allow unauthorized access to random people" 8-/? And then it turns out after a panicked investigation that only some LDAP configurations are vulnerable (not including mine), and even if vulnerable, other than some theoretical issue with confusing a client, there's really not much of a security problem going on. So rather than "MUST UPGRADE NOW!", It's more like "IF you use BindLdapAuthenticationHandler, you should probably upgrade soon to avoid potential as yet unknown issues". . -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: J. Tozo > Sent: Thursday, January 22, 2015 1:06 PM > > Its can be considered a minor weakness because it makes easier to > successfully You know what you don't do for a "minor weakness"? Publish a CVE with a title including "allows remote attackers to bypass LDAP authentication via crafted wildcards". Because you know what it means to "bypass authentication"? It means you don't have to authenticate, and can gain access to resources without knowing a valid username/password. Which made it seem pretty silly to get to the middle of your posting and see " A valid username and password required". Really? If I know a username and password, I can "bypass" authentication for *that* user? Wow, that's serious 8-/. Not. > perpetrate a bruteforce attack. Using common passwords and guessing the > username using the wildcards. Then perhaps you should've titled your CVE "allows remote attackers to more easily bruteforce access with limited knowledge of usernames"? Of course, given the limitation that the wildcard must match one and exactly one user kind of limits even that vulnerability. > A valid username and a password is required to you simulate if you system > have > or not this vulnerability. Actually, all that is required to determine whether or not your implementation has this vulnerability is to look at your configuration and see if you're using the FastBindLdapAuthenticationHandler or the BindLdapAuthenticationHandler. If it's the former, you are simply not vulnerable. Period. And even if the latter, there is no "authentication bypass" occurring. > If you need to upgrade or not your server its up to you to decide! That's true. And you know what I would appreciate to help me decide? Accurate vulnerability assessment and reporting. Perhaps some advanced notice a security update is coming out. As opposed to an email delivered in the middle of the night (at least in my time zone), which says there is a "security fix" for CVE-2015-1169 and "You must upgrade if you use LDAP authentication." And an artificially inflaming title for said CVE declaring there is a "remote attacker authentication bypass" vulnerability. I had better things to do this morning then spend two hours in a panic worried my authentication systems were susceptible to a serious security vulnerability. When in actuality other than your theoretical "bruteforce more easily" issue, even if your system is "vulnerable" to this, there is no known practical security implication thereof. And anybody using the fast bind implementation is simply not vulnerable. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: J. Tozo > Sent: Friday, January 23, 2015 10:28 AM > > I was not aware of the issue wasn't present in the fast bind ldap > authentication > because I discovered it in my own deployment, a year ago. [...] > I thought reasonable to write a small report about it, the > way i see it could hit my own environment. If you did not fully understand the vulnerability, you should not have requested a CVE, and you should not have posted an inaccurate announcement to a security list. What would have been "reasonable" would have been to post this to the cas-users mailing list for discussion. There is an (understandable) assumption that "security researchers" will actually *research* a vulnerability before requesting a CVE, and post an accurate analysis. You posted a poorly written half-ass embarrassment with a flagrantly false title which didn't even come close to rigorously describing the underlying issue. > You cant deny Its a authentication issue in an authentication system I never denied it's an authentication bug in an authentication system. What I *said* was that it is in no way an authentication *bypass*. Let me help you out: http://www.thefreedictionary.com/bypass In a security report such as you posted, typically the definition used would be "A means of circumvention". Tell me, how exactly does this issue let you "circumvent" authentication? You need to know a sufficient amount about the username to construct a wildcard that matches it, exactly it, and nothing else in the user base, *and* you need to know the password for that user. That's not bypassing or circumventing authentication. I get the impression you are not a native English speaker, which is excusable, but if you want to play in the big leagues and post vulnerability reports to security mailing lists, you need to understand the terminology sufficiently to accurately use it. > if you really believe that there is no practical > security implication, so we have nothing to talk. You have described no practical security implications, other than a fanciful attempt at how it might be used in a brute force attack. I do not believe there is any practical security implications because none have been demonstrated. *You* are the one that seems to think this is a serious security issue, *you* are the one that needs to explain why. So clearly if we have nothing to talk about, it is because *you* can't think of any. > if you spent two hours to > figure out if your system is vulnerable or not I think you have another > problem I did not spend two hours figuring out if my system is vulnerable. Once I reviewed in more detail your report it was fairly obvious it was not. What I did spend two hours doing was actually analyzing the problem, what you should've done before reporting it, and posting to the mailing list regarding it. The only problem I had was wasting time cleaning up the mess you made with an unprofessional and incompetent security report. > you do not like the way its written, pay someone to write the security > reports as > you wish (or do it by yourself) and stop complaining about to do your job in a > public mail list, if its not good then just quit. If you don't want to receive constructive criticism, maybe you shouldn't post your crap on public mailing lists. It's pretty clear you are just some kid who thought it would be "cool" to get a CVE and publish a security report. I'm frankly surprised Mitre even gave you one, I thought there was at least some limited assessment of reports before assignment. So your response to "you did a bad job on this" is "I would've done it better if you paid me"? Hah. I'm not complaining about my job, I'm complaining about yours 8-/. Like it or not, when you request a CVE and publish an official report, you are beholden to the community to do a reasonable job and there are actual consequences to your actions. The next time you decide to publish a security issue, I hope for your sake and everyone else's you actually spend the time to analyze and fully understand it, and write an accurate report with a reasonable assessment of the true vulnerability and exposure risks. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS Client Proxy distributed cache size
> From: Adam Causey > Sent: Friday, January 23, 2015 7:07 AM > > I originally was going with ehcache since there is a TicketStorage > implementation already available, but then realized how easy it would be to > create my own Hazelcast version. I'm not sure what you mean about creating your own version? I am using the unicon implementation: https://github.com/Unicon/cas-addons/wiki/Configuring-HazelcastTicketRegistry -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: Marvin Addison > Sent: Friday, January 23, 2015 11:59 AM > > Paul, I get your frustration and I can sympathize. Thanks. Sorry I did get a bit grumpy; I had some maintenance work scheduled for Thursday morning, and by the time I sorted out that this was not a critical security issue needing immediate attention I ended up having to postpone it . > On balance, we felt it best to have a patched version available for > download _prior_ to the CVE getting published. Absolutely. It just would have been nice had the announcement of the patched version more accurately assessed the vulnerability and criticality thereof. > As for the CVE text itself, I have > no idea where it came from. I don't believe it came from the core dev team. It appears to have come from J. Tozo allegedly of the "Alligator Security Team". If you Google that, you find a couple of other posts attributed to that group, but the authors of those posts identified themselves with @alligatorteam.org addresses as opposed to this guy, whose address appears to be junior...@gmail.com. Interestingly, he posted a very similar "exploit" in a different software package: http://seclists.org/oss-sec/2014/q4/1130 However, that one is labeled a "Web LDAP Injection", which is a touch more accurate. (Hey J. Tozo, why isn't that issue, almost identical to this one, also an "authentication bypass"?) While it was clear you guys did not write the CVE, you did reference it in your official announcement, which gave it some implicit authority and assumption of accuracy which it clearly did not deserve. Given CAS is authentication software, typically a critical part of an identity management infrastructure, I guess I was holding you guys to a bit of a higher standard in terms of handling security issues :). This was certainly a bug, a bug deserving of being fixed, and worth an upgrade if you are affected. But it is in no way an "authentication bypass", and it hardly deserves to be scheduled as an emergency "must" update. Anyway, to end on a more positive note; CAS is great software and has been working very well for us. We much appreciate the work that goes into it and I'm sorry I was a bit harsh on you guys regarding this incident. Thanks… -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: J. Tozo > Sent: Friday, January 23, 2015 1:52 PM > > So you saying if I bruteforce a CAS server with a common password list and > achieve an authentication within the user h*. that is not a authentication > bypass? Yes, that is exactly what I'm saying. > nice, in your world maybe. Actually, I believe any competent security researcher or analyst would agree with me. Please feel free to find one who does not and reference them. So from your perspective, if I go bruteforce gmail with your address junior...@gmail.com and a password list, and eventually determine your password, then access your mail with your password that I have discovered, I have "bypassed authentication"? That is ridiculous. When you bruteforce an account, and then access it using the credentials you have discovered, you are actually performing authentication with those credentials, not bypassing it. Bypassing, if you would bother to read the definition I provided, inherently involves something not occurring, being routed around, or avoided. You're not avoiding authentication, authentication is certainly not occurring. You are *performing* authentication with valid credentials, regardless of how you obtained them. And the chances of you being able to exploit this issue using the username "h*" are infinitesimally small, as there would have to be one and exactly one account that starts with an h, as if the wildcard matches multiple accounts authentication fails. So yes, this issue does allow you to potentially specify less than an exact username in an attempted authentication. But given the limitation that the wildcard must match one and only one account, you need to know so much about how the usernames of the entity being attacked are distributed it provides minimal excess leverage over a plain jane brute force attack using actual usernames. > You can cry, kicking around, panic, call me incompetent or whatever ad > hominem you want Actually, I am writing clear, grammatically correct, and well presented logical arguments and analysis making my case. It is rather you who are projecting the image of a child in a tantrum beating their hands and feet on the ground because someone has the audacity not to agree with them. > this still is an authentication bypass. No, it is not. And if you want to make anybody believe it is, you're going to need to do more than just keep crying "Yes it is! Yes it is! Yes it is!", you are going to need to present an actual analysis and logical argument demonstrating how this vulnerability meets the security industry standard understanding of bypassing authentication. You haven't done that, and you won't be able to do that, because it does not. > If you dont agree, > ask the dev team to rollback the update That would be silly. I've never once claimed this was not a bug, nor that it did not deserve to be fixed. It absolutely is a bug, and I wouldn't even argue it is not a security bug. However, it is a minimal issue with minimal exposure and little vulnerability in practice. It did not deserve being treated like a critical issue requiring immediate attention. > and ask mitre to revoke the CVE. I suppose I wouldn't even argue it doesn't deserve a CVE, at least if the description were accurate and actually contained an analysis of the underlying issue. But a CVE attached to your drivel? That probably should be revoked. > And last, this flame will lead us to nowhere, haters gonna hate and i will > not feed > this troll anymore. Nothing will make me more happy than if you stop beating this dead horse and wasting my time. You wrote a poorly constructed inaccurate CVE with minimal analysis and an artificially inflammatory title that resulted in a rushed security announcement mischaracterizing the vulnerability. Deal with it. Try to do better next time. Also, I'd have to care about you to hate you ;), so drop the persecution attitude. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CAS server release v3.5.3
> From: J. Tozo > Sent: Friday, January 23, 2015 3:35 PM > > http://www-01.ibm.com/support/docview.wss?uid=swg21682946 Nice try (just to be polite), but sorry, fail. The title of the IBM bulletin is "Brute-force attack in ClearQuest Web". The detailed description is "IBM Rational ClearQuest could allow a remote attacker to bypass security restrictions, caused by an error in the login form. An attacker could exploit this vulnerability using brute-force techniques to gain access to a user's account." The actual CVE (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3101) description is "The login form in the Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not insert a delay after a failed authentication attempt, which makes it easier for remote attackers to obtain access via a brute-force attack." So exactly what in any of that are you interpreting as "bypassing authentication"? While the IBM description does indeed include the word "bypass" (but note the actual CVE does not), it says the issue allows you "to bypass security restrictions", not "bypass authentication". If you actually read the bulletin, you will see the problem under discussion is that the web form did not have any mechanism to alleviate against a brute force attack. You could feed it usernames and passwords as fast as the network would allow you to. Honestly, I don't even know if that could be classified as an "error in the login form" so much as the lack of an anti-brute forcing feature. While you did manage to find a document that contained the words "bypass", "bruteforce", and "authentication", it really has no bearing on your CVE nor in any way supports or defends your position that your CVE in any way describes a vulnerability that "bypasses authentication". For the most part, your presentation of this document simply further solidifies my opinion on your lack of understanding of security concepts and basic terminology, as well as your inability to analyze and properly classify security vulnerabilities. But feel free to try again. I suppose shooting fish in a barrel isn't very sportsmanlike, but sometimes it does offer a perverse level of enjoyment. And perhaps is even a bit cathartic after the annoyance you caused me yesterday morning. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS Client Proxy distributed cache size
On Fri, Jan 23, 2015 at 02:03:39PM -0800, Misagh Moayyed wrote: > I think Adam is talking about the sharing and distribution of PGTs on the > client side for which there are ehcache and memcache implementations > available when the app is clustered. There is no implementation yet > available that is based on hazelcast for the client. Ah, my bad, I misread this thread and thought it was talking about clustering on the server side. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS server release v3.5.3
On Sat, Jan 24, 2015 at 01:08:46AM -0800, Jérôme LELEU wrote: >I planned not to interfere in this discussion, but seriously we should >stop it now. Sorry for the noise. Assuming the other party gives up trying to defend his inaccurate CVE, I've got nothing else to say about it. >I made the announcement and I reviewed and agreed to the CVE: so I'll >take my full part of responsability if things are not clear. You really agreed to the characterization of this as an "authentication bypass"? >No "critical" word. Maybe I should have said "minor".  I did not say >"you should upgrade NOW!". "Must" has quite a different connotation than "should". And while your announcement didn't contain "critical", the CVE referenced claimed there was an "authentication bypass", and what sysadmin isn't going to take "security fix" "must update" and "authentication bypass" as anything but a critical issue? >I think "LDAP login with wildcards" is a reasonable description. I agree. With your announcement exactly as it was, and a CVE entitled more along the lines of "LDAP login with wildcards allows authentication with partial username match" there wouldn't have been such an inaccurate sense of urgency. >I don't think we can always imagine all use cases and data topology, so >one must be careful and upgrade to 3.5.3, even it's not in a hurry. Yes, it's generally a best practice to run the most recent stable version of a software package, after appropriate review of changes and testing, and deployment scheduled for a regular maintenance window. Which we will likely do. The issue was, intentionally or not, the combination of the announcement and the inaccurate CVE gave an impression that this was an important update that needed attention ASAP, possibly even requiring an emergency out of window update. Am I really the only one here that read the announcement, looked up the CVE, and initially came to that inaccurate assessment? >we haven't created a CVE, I'm sure someone would have blame us for >that. CVE's are given to issues minor or critical, so I've no complaints about the CVE per se, just that it was poorly written. >But, above all, I'd like to remind you about the great efforts and >the good will of the volunteers of the CAS community. We deserve >more clemency (we are not all in the same timezones and are not all >fluent in English) and courtesy. I believe I already mentioned in another message in this thread how much we appreciate the CAS software and the efforts of the developers. While from a constructive criticism perspective the official CAS announcement could have been handed better, the primary issue was the misleading CVE title. I probably could have dealt with this a bit more diplomatically, the interruption to my planned schedule and fallout therefrom put me in a bit of a bad mood, and for that I apologize. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS server release v3.5.3
On Sat, Jan 24, 2015 at 02:43:59AM -0800, Yuri Ticini wrote: >Congratulations buddies, you managed to turn a simple release >announcement containing a relevant security fix into one of the biggest >bikeshedding episodes I've seen recently Bikeshedding? Really? A member of a mailing list for *security* software thinks it's *bikeshedding* to insist on an accurate description, assessment, and analysis of a *security* issue? Sheesh. I guess maybe I should have taken this discussion over to oss-security or fulldisclosure. >just because of an annoyed >fella that didnât like the description of the CVE. Cry me a river whiny >boy! Annoyed? Absolutely. Whiny? Please. Grumpy maybe, but whiny no. And it's not "didn't like" as in "I don't like the color red", it's "inaccurate" as in "completely misleading and misusing technical terminology with a standard definition in the security community". >Can we get back to work now? I already updated all my CAS deployments >while you had this crappy conversation. Never heard of a killfile? Nobody put a gun to your head and forced you to read it, if you don't actually care about the underlying details of the bugs fixed in a new version you already updated to, feel free to skim on past. I guess you don't have a very rigorous testing process if you've already dropped this into production in a couple days. I haven't updated my CAS deployments because, well, this crappy conversation demonstrated quite clearly I didn't need to. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS server release v3.5.3
On Sat, Jan 24, 2015 at 08:17:08PM -0800, Yuri Ticini wrote: >Oh man, are you still here insisting with this bullshit? How old are >you, fourteen? [...] >Does that mean you're above all these people? If that's >the case, why you're keeping your silly sysadmin job? Go for the gold >man, you're probably a rare genius! [...] >And apparently you don't even understand how LDAP >searches work with wildcards, so why bother? [...] >Ah, and one more thing: trying to justify your recent douche behavior >on "a bit of a bad mood" is coward. Go find yourself a therapist. [...] >I'm following your advice and >forwarding messages from you to Junk. I'm not interested at all in what >you have to say. Therefore, feel free to try to pretend to be smart and >superior responding to this Throw unfounded petty insults right and left and then say don't bother to reply because you won't read it? Doesn't matter to me you won't see this, but for the people that do I think that speaks for itself. And for the record, I've had off-list correspondence with a number of people, some of them directly associated with the project, who agree with me the announcement was poorly handled and the CVE poorly written. It seems I'm just the only one with the lack of tact to call it out in public. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS and EZproxy
On Wed, Feb 11, 2015 at 04:30:59PM +, Chris Adams wrote: > I have read documentation for using CAS with Ezproxy and it seems to > agree with some postings on this list. However, I am missing something > and thought someone here might want to weigh in. We use CAS for ezproxy with attributes for authorization, our config looks like: ::CAS LoginURL https://auth.csupomona.edu/cas/login ServiceValidateURL https://auth.csupomona.edu/cas/serviceValidate Group NULL Test //*/cas:csupomonaEduPersonAffiliation employee ; Group +authorized Test //*/cas:csupomonaEduPersonAffiliation student ; Group +authorized Test //*/cas:csupomonaEduPersonAffiliation leave_student ; Group +authorized Test //*/cas:csupomonaEduPersonAffiliation emeritus ; Group +authorized NoGroups; Deny unauthorized.html /CAS When I load a proxied URL such as: http://proxy.library.csupomona.edu/login?url=http://veterinaryrecord.bmj.com/content/current I get redirected to CAS: https://auth.csupomona.edu/cas/login?service=http%3a%2f%2fproxy.library.csupomona.edu%2flogin%3fqurl%3dezp.2aHR0cDovL3ZldGVyaW5hcnlyZWNvcmQuYm1qLmNvbS9jb250ZW50L2N1cnJlbnQ- and after authenticating, end up at the proxied page: http://veterinaryrecord.bmj.com.proxy.library.csupomona.edu/content/current We've never had an issue with it. I'm not sure what's causing your double authentication, maybe some other part of the config? -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Recommendations for CAS/LDAP integration work
On Mon, Mar 16, 2015 at 04:07:46PM -0700, Andrew Morgan wrote: > We are big fans of Unicon (http://unicon.net). They are very involved in > the open source community surrounding Identity Management. You'll find I'd second that opinion; while we deployed CAS with in-house staff, our apps group had them out to help with a uportal deployment. We also use their hazelcast ticket registry backend and their shib-cas-authn2 plugin to delegate our shibboleth idp authentication to CAS. I've found every unicon staff member I've been in contact with to be skilled, professional, and amazingly helpful even for non-paid interactions, I can't imagine you could go wrong engaging them. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Casifying Shib (idP)
On Wed, Mar 18, 2015 at 05:03:53PM +, Niva Agmon wrote: > We looking to implement CAS as the Authentication provider for Shib > IDP. Have you looked at Unicon's shib-cas-authn2 package? https://github.com/Unicon/shib-cas-authn2 That's what we use and it works great. As I recall it was also fairly easy to set up. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Casifying Shib (idP)
On Wed, Mar 18, 2015 at 10:34:49PM +, Niva Agmon wrote: > javax.security.auth.login.LoginException: No LoginModules configured for > ShibUserPassAuth > at javax.security.auth.login.LoginContext.init(LoginContext.java:287) > ~[na:1.6.0_32] > at > javax.security.auth.login.LoginContext.(LoginContext.java:432) > ~[na:1.6.0_32] > > Thanks again for any help or tips. Hmm, did you update handler.xml? Here's what mine looks like: urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified Basically, I commented out the "UsernamePassword" login handler to disable shib's native auth, added the "shib-cas:CasLoginHandler" to enable CAS auth, and disabled the "PreviousSession" handler as session state is handled on the CAS side, not the shib side. As I recall, the instructions are pretty accurate. Update web.xml, create the external properties file, update handler.xml... Install the idp-cas-invoker and cas-client-core jars, and you should be good to go. If you double check these steps and it still doesn't work you might try asking on the shib list, there's some crossover between this one but they might have a better idea on this shib specific error. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] OT: change email in jira
We're changing our domain name, and I need to update my email in the jasig issue tracker. However, I don't see an email address listed on my profile page? Based on the jira help, it should be. I know it has my old address as I've received email in the past and the avatar section shows it. Am I missing something? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] CASifying web applications
We're at a point in our CAS deployment where we'd like to start converting some of our existing applications to use it, and I'd appreciate some feedback on the best path to do so. It seems there are two types of webapps under consideration, those that do no authentication at all on their own and rely entirely on web service based authentication, and those that have no web server authentication and implement auth entirely on their own. For web server auth, it looks like the only real solution is mod_auth_cas (https://wiki.jasig.org/display/CASC/mod_auth_cas) for Apache? Anyone currently using this that might be able to comment on how well it works, how reliable it is, etc? It looks like it doesn't support proxy authentication, but we only have one app that needs that. Does anyone know if this module works as-is under Apache 2.4? According to the docs, some 2.2 modules work fine under 2.4, while others require updates for certain changed API's. If the app is mod_perl based, or mod_perl can be added just for authentication, it looks like there are two options: http://search.cpan.org/~dcastro/Apache-AuthCAS/lib/Apache/AuthCAS.pm http://search.cpan.org/~jhitt/Apache2-AuthCAS-0.4/lib/Apache2/AuthCAS.pm Any opinion/consensus on which of these is better, and how they compare to mod_auth_cas? It looks like both of these support proxy auth, which makes them presumably beat out mod_auth_cas for that use case. For applications which do their own authentication, it looks like phpCAS (https://wiki.jasig.org/display/CASC/phpCAS) is the officially supported solution for php based apps? For perl based applications, I see there's only an unofficial client available (https://github.com/Unicon/cas-perl-client). The last update is over 3 years ago, and the documentation is a bit lacking. There are no better solutions for CAS via perl? We have one app that will need to do proxy auth, it's part of our idm infrastructure. The client facing front end is on a windows box, currently doing forms based auth and proxying the plaintext credentials to a mod_perl based web service via apache ldap authentication. To CASify this, our webapps group will presumably use the .net CAS client to authenticate the browser and then use CAS proxy auth to authenticate the end user to the web service. We are flexible on this as to whether the auth is done by the web server or integrated into the app itself. As mod_auth_cas doesn't do proxy auth, that is ruled out. Any thoughts on whether it would be cleaner to use one of the mod_perl based solutions to do the proxy auth at the web server level vs a perl CAS client in the application? Thanks much... -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CASifying web applications
> From: Waldbieser, Carl > Sent: Thursday, April 23, 2015 6:20 AM > > We are using mod_auth_cas in front of a couple web apps, and it works pretty > much as you would expect. Since it is a fairly decoupled integration with > your > web app, the "log out" links in your web app will tend not to work the way one > might expect. Cool, thanks for the feedback. The majority of the applications we would switch to mod_auth_cas already use web server-based authentication, so they don't really have logout buttons, that shouldn't be a problem. > I can't speak to the perl modules you mention, but a lack of activity is not > necessarily a bad thing. CAS is a relatively simple and straightforward > protocol. > The code for a CAS client should tend to stabilize pretty quickly. True; although CAS 4 has been out for a while, with a new version of the protocol. Not seeing any changes at all for 3-4 years, whether bug fixes, enhancements, or updated protocol support, makes one concerned they are not really maintained. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] CASifying web applications
> From: Christopher Myers > Sent: Thursday, April 23, 2015 6:31 AM > > For the Java CAS stuff, you may want to check out the "sample" webapp > provided here: https://wiki.jasig.org/display/CASC/JA- > SIG+Java+Client+Simple+WebApp+Sample - it gives you a really good, simple > overview of how stuff is set up. We don't currently have any java apps in need of CASification, but I'll keep this in mind, thanks. -- Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ Operating Systems and Network Analyst | hen...@cpp.edu California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
