Re: [cas-user] shib idp 3 CAS support
As the matter of fact we have done so :-) The implementation needs some polishing before it could be publicly announced (on the shib lists), but it's coming :-) Have a great weekend. D. Sent from my iPhone On Jul 18, 2015, at 15:58, Paul B. Henson hen...@cpp.edu wrote: On Fri, Jul 17, 2015 at 03:25:35PM -0400, Dmitriy Kopylenko wrote: Just want to conclude this thread with a pretty good read about Hazelcast So... Any chance you guys at Unicon have any interest in putting together a Hazelcast based clustering backend for idp 3 :)? -- 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: dkopyle...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- 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 idp 3 CAS support
On Fri, Jul 17, 2015 at 03:25:35PM -0400, Dmitriy Kopylenko wrote: Just want to conclude this thread with a pretty good read about Hazelcast So... Any chance you guys at Unicon have any interest in putting together a Hazelcast based clustering backend for idp 3 :)? -- 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] shib idp 3 CAS support
On Sat, Jul 18, 2015 at 04:29:55PM -0400, Dmitriy Kopylenko wrote: As the matter of fact we have done so :-) The implementation needs some polishing before it could be publicly announced (on the shib lists), but it's coming :-) Sweet. If it's not out before I get around to testing idp 3 I might bug you to beta test :). 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] shib idp 3 CAS support
Just want to conclude this thread with a pretty good read about Hazelcast. Arguably, by now Hazelcast software (at v3.5) is a pretty robust, well-implement and mature distributed grid/cache. http://www.brickendon.com/articles/achieving-low-latency-using-distributed-cache/ http://www.brickendon.com/articles/achieving-low-latency-using-distributed-cache/ Best, D. On Jul 14, 2015, at 3:32 PM, Paul B. Henson hen...@cpp.edu wrote: From: Marvin Addison Sent: Tuesday, July 14, 2015 6:33 AM Correct. What makes this acceptable in many if not most cases is that the lost state is SSO state where the effect on the user is to log in again. As failure modes go, that's graceful behavior. Arguably true, but still not optimal :). Contrary to what seems to be the average deployment, I also encrypt the cluster replication traffic over the wire, so I perhaps have stricter requirements for perfection than generally considered ;). Peer-to-peer replication incurs a cost and in my experience the failure modes of replication are orders of magnitude worse than anything I've seen with memcached. Perhaps over time Hazelcast will prove itself both reliable and fault tolerant, but it's patently new technology at this point and needs some road time to convince me. I load tested it pretty heavily including random node restarts and it never blipped. We've been running it in production for about a year and a half and I haven't seen a single problem (knock on wood). We've probably done at least 4-5 rolling updates since then where we pulled a node out of the cluster and then stuck it back in, I'm unaware of any user facing issues or unnecessary re-authentications. In any case, I'm pretty happy with it :), and wouldn't really want to trade it out for memcached. 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: dkopyle...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- 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 idp 3 CAS support
The primary reason I did not like the memcached implementation was that it is not truly fault-tolerant. As I understand it, any given key is hashed and stored on one of the available memcached nodes. A client that needs it performs the same hash, and tries to retrieve it from the same node. I have a three node CAS cluster. With the memcached ticket registry, if one of the nodes were to crash, I would simply lose a third of my state. Correct. What makes this acceptable in many if not most cases is that the lost state is SSO state where the effect on the user is to log in again. As failure modes go, that's graceful behavior. On the other hand, with the hazelcast ticket registry backend, a backup copy of the state on any given node is available on another node, and if you lose only a single node, you lose no state. Peer-to-peer replication incurs a cost and in my experience the failure modes of replication are orders of magnitude worse than anything I've seen with memcached. Perhaps over time Hazelcast will prove itself both reliable and fault tolerant, but it's patently new technology at this point and needs some road time to convince me. Best, M -- 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 idp 3 CAS support
From: Marvin Addison Sent: Tuesday, July 14, 2015 6:33 AM Correct. What makes this acceptable in many if not most cases is that the lost state is SSO state where the effect on the user is to log in again. As failure modes go, that's graceful behavior. Arguably true, but still not optimal :). Contrary to what seems to be the average deployment, I also encrypt the cluster replication traffic over the wire, so I perhaps have stricter requirements for perfection than generally considered ;). Peer-to-peer replication incurs a cost and in my experience the failure modes of replication are orders of magnitude worse than anything I've seen with memcached. Perhaps over time Hazelcast will prove itself both reliable and fault tolerant, but it's patently new technology at this point and needs some road time to convince me. I load tested it pretty heavily including random node restarts and it never blipped. We've been running it in production for about a year and a half and I haven't seen a single problem (knock on wood). We've probably done at least 4-5 rolling updates since then where we pulled a node out of the cluster and then stuck it back in, I'm unaware of any user facing issues or unnecessary re-authentications. In any case, I'm pretty happy with it :), and wouldn't really want to trade it out for memcached. 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] shib idp 3 CAS support
Would the idp multifactor mechanisms be usable for CAS clients? Yes, though it may be better to discuss further on the related shib-users thread. I don't particularly like the memcached backend, which looks like the only current option (other than a database) to cluster idp 3. I'd be curious to know why you don't like it. I encourage you to discuss further on shib-users. Yes, from what I've seen the attribute filter basically functions as the service registry for CAS clients, but gives you the idp feature of only allowing certain values of some attributes rather than all. The ability to mutate attributes is a notable capability of the IdP attribute engine. I need to decide whether to keep a separate CAS deployment ... or migrate CAS clients to the idp CAS support. I was in the same situation, so I'll share my decision FWIW. I'm a single FTE running two production systems, Shib IdP and Jasig CAS server, that have the same purpose but with complementary capabilities. It made all the sense in the world to consolidate onto a single platform that could provide everything we needed. Fortunately I had the benefit of developing the CAS protocol support in the IdP expressly to meet our requirements. Thus we had assurance our needs would be met by a single platform and it became a straightforward economic decision: consolidate and save. Of course our needs and yours are likely different; you'll have to evaluate for yourself whether a single platform meets your requirements. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- 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 idp 3 CAS support
On Sun, Jul 12, 2015 at 11:54:34PM +, Marvin Addison wrote: I'm very familiar with both from a development and deployment perspective. Much of the growth of Jasig CAS over the past several years has been in the area of multi-protocol support, so you'll lose anything that's not CAS or SAML; OAuth protocol support comes to mind. That's probably the biggest functional area of distinction. We don't currently use OAuth, and I don't think we have any short to mid-term plans to. We are going to be looking at multifactor authentication soon though. I'm not that familiar with them, but I know both CAS and shib idp have mechanisms for integrating multifactor. Would the idp multifactor mechanisms be usable for CAS clients? I would say Jasig CAS has more mature management capabilities; the service manager UI comes to mind immediately. I actually use the Unicon JSON backend in read-only mode, the config file itself is stored under version control. So no worries there :). and effort before the IdP catches up in that area. There are also a lot more integration options for Jasig CAS, mostly in the area of storage backends like Ehcache and Hazelcast. Again, it's easy to develop these Yeah, I gotta say I love the Hazelcast ticket registry. After fighting with the ehcache one for a month or so it was much easier to get working the way I wanted and we haven't had any problems with it. I don't particularly like the memcached backend, which looks like the only current option (other than a database) to cluster idp 3. We currently delegate idp authentication to CAS, and don't enable the idp backdoor port or artifact resolution, so my current idp deployment uses stateless clustering. Works really well so far. things for the IdP and they will probably emerge in the near future if folks need or want them. On balance, the attribute engine of the IdP is a powerful capability that has no analogue in Jasig CAS. Yes, from what I've seen the attribute filter basically functions as the service registry for CAS clients, but gives you the idp feature of only allowing certain values of some attributes rather than all. I could probably come up with some more pros and cons to discuss, but the ones I've listed seem most notable to me as a deployer. If there are any features of interest to you in particular, please mention them and we can discuss further. Thanks. I'm not necessarily sure what interests me in particular at this point ;), I don't know what I don't know :). As I mentioned, we're definitely going to upgrade to idp 3 this year, and I need to decide whether to keep a separate CAS deployment (and upgrade it to 4.1 when it's released) or migrate CAS clients to the idp CAS support. That decision is really going to drive how I deploy idp 3, if auth remains delegated to CAS it will likely be stateless clustering; otherwise, I'll need to either set it up with a stateful backend or revert to our previous active/passive failover idp deployment. -- 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] shib idp 3 CAS support
I was just wondering if anybody here is familiar with both and might be able to provide some pros/cons of consolidating CAS into the idp vs continuing to maintain a separate CAS deployment? I'm very familiar with both from a development and deployment perspective. Much of the growth of Jasig CAS over the past several years has been in the area of multi-protocol support, so you'll lose anything that's not CAS or SAML; OAuth protocol support comes to mind. That's probably the biggest functional area of distinction. I would say Jasig CAS has more mature management capabilities; the service manager UI comes to mind immediately. That said, it's only a matter of time and effort before the IdP catches up in that area. There are also a lot more integration options for Jasig CAS, mostly in the area of storage backends like Ehcache and Hazelcast. Again, it's easy to develop these things for the IdP and they will probably emerge in the near future if folks need or want them. On balance, the attribute engine of the IdP is a powerful capability that has no analogue in Jasig CAS. I could probably come up with some more pros and cons to discuss, but the ones I've listed seem most notable to me as a deployer. If there are any features of interest to you in particular, please mention them and we can discuss further. Best, M -- 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
