On Sun, Jul 12, 2015 at 11:54:34PM +0000, 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  |  [email protected]
California State Polytechnic University  |  Pomona CA 91768

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to