[07:57:13 CDT(-0500)] <foxnesn> morning
[12:41:40 CDT(-0500)] <atilling> cd
[12:43:07 CDT(-0500)] <foxnesn> hi
[12:43:59 CDT(-0500)] <foxnesn> atilling, your HA environment do you keep your database separate from the cas server or do you have a database on each cas server having them replicate data?
[12:44:22 CDT(-0500)] <foxnesn> so do you have 1 db where both cas servers point to
[12:44:36 CDT(-0500)] <foxnesn> or does each cas server have its own database with replication of the db
[12:44:45 CDT(-0500)] <atilling> depends 
[12:44:49 CDT(-0500)] <foxnesn> o?
[12:45:22 CDT(-0500)] <atilling> for our password management there is one certral DB server that CAS writes to
[12:45:36 CDT(-0500)] <foxnesn> ok
[12:45:45 CDT(-0500)] <foxnesn> what about ticket registry?
[12:45:49 CDT(-0500)] <atilling> for service registry there is a replicated database on each cas server
[12:45:56 CDT(-0500)] <foxnesn> ahh
[12:46:09 CDT(-0500)] <atilling> for ticket registry we use ehcache in RMI mode
[12:46:09 CDT(-0500)] <foxnesn> by service registry doyou mean ticket reg?
[12:46:14 CDT(-0500)] <foxnesn> oh
[12:46:56 CDT(-0500)] <foxnesn> so service registry is for /cas/services
[12:47:05 CDT(-0500)] <atilling> correct
[12:47:05 CDT(-0500)] <foxnesn> keeping that on a db instead of in memory
[12:47:48 CDT(-0500)] <atilling> Right because we have deffined services and have themes and attributes managed accrossed the services
[12:48:01 CDT(-0500)] <foxnesn> hrm
[12:48:59 CDT(-0500)] <foxnesn> maybe we just keep service reg in memory and force it in the deployer
[12:49:28 CDT(-0500)] <foxnesn> for tix reg did you follow this
[12:49:37 CDT(-0500)] <foxnesn> https://wiki.jasig.org/display/CASUM/JpaTicketRegistry
[12:54:13 CDT(-0500)] <foxnesn> o u use ehcache
[12:54:40 CDT(-0500)] <atilling> we used the same JPA for service reg but not tickets
[12:54:58 CDT(-0500)] <atilling> we're using this for tickets: https://wiki.jasig.org/display/CASUM/EhcacheTicketRegistry
[12:55:40 CDT(-0500)] <foxnesn> i see
[12:56:05 CDT(-0500)] <foxnesn> also could you tell me if my solution to webflow is secure?
[12:56:17 CDT(-0500)] <foxnesn> ill show you the code for the forward url i used
[12:56:33 CDT(-0500)] <atilling> we had the ehcache set up before we did service registry
[12:57:20 CDT(-0500)] <atilling> If we had the service reg is JPA first we might have gone JPA for tickets too
[12:57:45 CDT(-0500)] <atilling> but our main goal was to have CAS as independant as possible
[12:58:08 CDT(-0500)] <foxnesn> https://pwm:8443/pwm/private...checkAll&forwardURL="https%3A%2F%2Fmoodle/login/index.php?"+request.getParameter("ticket"
;
[12:58:24 CDT(-0500)] <atilling> with JPA ticketReg CAS depends on MyQL
[12:58:53 CDT(-0500)] <foxnesn> the request.getParameter appends the ticket to the url
[12:58:57 CDT(-0500)] <foxnesn> it works great
[12:59:06 CDT(-0500)] <foxnesn> not sure if it is secure tho
[12:59:23 CDT(-0500)] <atilling> Looks good to me, there aren't passwords exchanged and when the PWM passes them to Moodle, moodle does the validate
[12:59:43 CDT(-0500)] <foxnesn> im assuing since it is built into the flow nobody can hijack the "ticker"
[12:59:46 CDT(-0500)] <foxnesn> "ticket"
[13:00:03 CDT(-0500)] <foxnesn> or have CAS send the ticket to another sesson
[13:00:07 CDT(-0500)] <atilling> the PWM is just passing on the service ticket so it's secure
[13:00:17 CDT(-0500)] <foxnesn> awesome
[13:00:30 CDT(-0500)] <foxnesn> i was worried i found a solution but it wouldnt be secure
[13:00:56 CDT(-0500)] <foxnesn> gonna have to install development portal to test it on