[07:31:33 CDT(-0500)] <ries> Good morning, I have a other related question to CAS. Is it up to CAS to allow/dely access to specific applications, even though the user is logged in. or is ut up to the application to say 'I know Scott, but you cannot access me'.
[07:31:48 CDT(-0500)] <ries> I am trying the understand the wiki here : https://wiki.jasig.org/display/CAS/Home
[07:31:59 CDT(-0500)] <ries> but it doesn't mention that
[07:32:47 CDT(-0500)] <wgthom> authZ is up to the app
[07:34:47 CDT(-0500)] <ries> wgthom: ok thanks…
[09:02:11 CDT(-0500)] <kickehy> I'm having trouble getting ssl to work with tomcat (using guide http://tinyurl.com/3v94ayy ) The only thing that i'm confused about in the server.xml file is the keystoreFile part...i imported my cert into cacerts and copied that file over to the conf tomcat folder (as the example did), but when I stop/start tomcat, I absolutely can't get to https://server:8443 Now, if I go to http://server:8080 it works, I must be missing something
[09:02:44 CDT(-0500)] <kickehy> I don't even get a response back from my cas server
[09:03:35 CDT(-0500)] <wgthom> make sure you have the ssl connecter in server.xml uncommented
[09:03:38 CDT(-0500)] <kickehy> and i changed the keystore to "conf/cacerts"
[09:03:51 CDT(-0500)] <kickehy> i'll double check here...
[09:04:27 CDT(-0500)] <kickehy> all good
[09:04:35 CDT(-0500)] <serac> The output of $TOMCAT_HOME/logs/localhost.log will have details.
[09:05:42 CDT(-0500)] <serac> I need to add a note to that page that discusses filesystem permissions for the keystore file.
[09:05:52 CDT(-0500)] <serac> It contains a private key, so security matters.
[09:06:10 CDT(-0500)] <serac> That's fundamentally different from the system key/truststore that contains exclusively certs by default.
[09:09:21 CDT(-0500)] <kickehy> localhost logs are empty :/
[09:09:49 CDT(-0500)] <serac> catalina.out?
[09:10:27 CDT(-0500)] <kickehy> hey there we go
[09:11:06 CDT(-0500)] <serac> 
[09:11:17 CDT(-0500)] <kickehy> w00t must of made my cert wrong then
[09:11:42 CDT(-0500)] <serac> What OS are you running?
[09:11:55 CDT(-0500)] <kickehy> Windows server 2008 r2
[09:12:20 CDT(-0500)] <serac> Wanna be a guinea pig?
[09:12:25 CDT(-0500)] <kickehy> haha sure
[09:12:50 CDT(-0500)] <serac> Generate a pfx file containing your cert/key pair.
[09:13:44 CDT(-0500)] <serac> PFX is mostly the same as a PKCS#12 container.
[09:14:01 CDT(-0500)] <kickehy> from the ca or local computer?
[09:14:23 CDT(-0500)] <serac> I assumed you used the certificate console to generate the cert. Is that correct?
[09:15:02 CDT(-0500)] <kickehy> yes, but this is where certs start to get over my head....i wasn't completely sure what type of template to request the cert as
[09:15:05 CDT(-0500)] <kickehy> so
[09:15:24 CDT(-0500)] <kickehy> i wasn't able to select the "mark as exportable" for the private key
[09:15:42 CDT(-0500)] <kickehy> or is that not what you're talking about?
[09:16:14 CDT(-0500)] <serac> How'd you get the key out for your JKS keystore file, then?
[09:16:37 CDT(-0500)] <serac> You must have the private key in your keystore.
[09:16:51 CDT(-0500)] <serac> (would explain failure if not)
[09:17:39 CDT(-0500)] <kickehy> well rather than using the example's ca (portecle) i used our server 2008 CA
[09:17:45 CDT(-0500)] <kickehy> to make it "official"
[09:18:16 CDT(-0500)] <kickehy> just an fyi, a lot of this is very new to me 
[09:18:23 CDT(-0500)] <serac> Sure, it's tough.
[09:18:38 CDT(-0500)] <kickehy> so i'm not sure how the .jks file works in all this
[09:18:44 CDT(-0500)] <kickehy> i assume i don't have one
[09:19:05 CDT(-0500)] <kickehy> as i imported the cert into the cacerts keystore, i assumed i would use that instead of the .jks file
[09:19:08 CDT(-0500)] <serac> conf/ssoServer.jks
[09:19:18 CDT(-0500)] <serac> ssoServer.jks = cacerts
[09:19:22 CDT(-0500)] <kickehy> ok
[09:19:41 CDT(-0500)] <serac> If you just imported the cert, you have only half of what's needed to configure an SSL server.
[09:20:04 CDT(-0500)] <serac> A server needs to possess the private key in order to encrypt an assertion that's sent to the client side that is decrypted with the public key.
[09:20:11 CDT(-0500)] <serac> Sans private key, SSL will never work.
[09:20:20 CDT(-0500)] <serac> So you must generate a key that's exportable.
[09:20:27 CDT(-0500)] <kickehy> ok
[09:20:29 CDT(-0500)] <serac> I use OpenSSL for this generally.
[09:20:39 CDT(-0500)] <serac> You should use whatever you're comfortable with.
[09:21:06 CDT(-0500)] <kickehy> have any experience setting up a CA on Windows?
[09:21:10 CDT(-0500)] <serac> Certificate MMC snap-in is a good choice, but I'm honestly only vaguely familiar with it. Mostly just guessing what to do.
[09:21:16 CDT(-0500)] <kickehy> heh
[09:21:30 CDT(-0500)] <serac> I use it for development/testing on Windows.
[09:21:36 CDT(-0500)] <serac> But no production experience.
[09:21:46 CDT(-0500)] <kickehy> my problem is that all my templates don't show up for my CA when i request a cert from the web interface
[09:22:17 CDT(-0500)] <serac> Yeah, can't help you there.
[09:22:22 CDT(-0500)] <kickehy> heh
[09:22:27 CDT(-0500)] <serac> All I can say is that you need to be able to export the private key.
[09:22:39 CDT(-0500)] <serac> PFX is the appropriate format on Windows.
[09:22:45 CDT(-0500)] <serac> From there should be easy.
[09:22:52 CDT(-0500)] <kickehy> mmmk I'll see if i can get that working first and i'll get back to ya
[09:23:01 CDT(-0500)] <serac> Sounds good.
[09:23:06 CDT(-0500)] <kickehy> thanks
[09:26:35 CDT(-0500)] <kickehy> one other thought, do i need to import the ca's cert into the store?
[09:27:23 CDT(-0500)] <serac> Yes. The exported PFX file should contain the complete certificate chain.
[09:27:33 CDT(-0500)] <kickehy> ok
[09:27:51 CDT(-0500)] <serac> While many browsers will blithely work without the full validation path, it's best practice.
[10:06:51 CDT(-0500)] <ries> Gents, if I go to : http://192.168.1.194:37210/cas/logout then I see Logout successful, should all my other apps be logged out?
[10:07:09 CDT(-0500)] <wgthom> it depends.
[10:07:23 CDT(-0500)] <wgthom> generally, no
[10:08:32 CDT(-0500)] <wgthom> unless you've configured all of your applications to deal with the SLO callback. and even then it's a crap shoot
[10:08:40 CDT(-0500)] <ries> ic...
[10:09:08 CDT(-0500)] <ries> I just quit my browsers, and one application showed the login, and the other app showed up again
[10:09:22 CDT(-0500)] <serac> Do you have session restore enabled? Firefox perhaps?
[10:09:46 CDT(-0500)] <ries> serac: Safari, I even have no idea how to turn it off 
[10:09:47 CDT(-0500)] <serac> Additionally, I'd recommend you treat "crap shoot" as hyperbole.
[10:11:08 CDT(-0500)] <serac> You should investigate the session storage behavior of Safari. I can't say for certain with Safari, but it's a known issue with FF for a particular configuration.
[10:11:25 CDT(-0500)] <ries> I wonder how you can logout somebody reliable...
[10:11:34 CDT(-0500)] <wgthom> logout of what?
[10:11:39 CDT(-0500)] <serac> It's a fundamentally hard problem.
[10:11:54 CDT(-0500)] <serac> To log out of everything accessed in an SSO session.
[10:11:54 CDT(-0500)] <ries> wgthom: logout, so that I get the login screen again
[10:12:16 CDT(-0500)] <ries> serac: I can imagine you need to go through each application and do some for of redirect...
[10:12:17 CDT(-0500)] <wgthom> logout of the application session? logout of cas sso session?
[10:13:09 CDT(-0500)] <serac> Some CAS clients have support for single sign out, but there are issues and limitations as wgthom implied.
[10:13:11 CDT(-0500)] <ries> application session 'I think'...
[10:13:15 CDT(-0500)] <wgthom> s/hard problem/crap shoot/
[10:13:27 CDT(-0500)] <ries> I can imagine it's a problem...
[10:13:46 CDT(-0500)] <ries> I am trying to setup a demo where my 'boss' can test it.. I am sure he wants to see a logout function somehow
[10:14:56 CDT(-0500)] <serac> You'll need to configure the clients single sign-out capability.
[10:15:01 CDT(-0500)] <serac> Java, php, .NET, what?
[10:15:17 CDT(-0500)] <ries> Java
[10:15:17 CDT(-0500)] <ries> +
[10:15:25 CDT(-0500)] <ries> only JSP pages for testing
[10:15:36 CDT(-0500)] <wgthom> re logout you'll have to thinking about what you want the behavior to be between app logout and sso "logout"
[10:15:39 CDT(-0500)] <serac> Have you read https://wiki.jasig.org/display/CASUM/Single+Sign+Out?
[10:16:02 CDT(-0500)] <serac> Here's the setup for Java client, https://wiki.jasig.org/display/CASC/Configuring+Single+Sign+Out.
[10:16:23 CDT(-0500)] <ries> thanks for the links
[10:16:27 CDT(-0500)] <wgthom> one perspective if CAS a psuedo application session manager. that's SLO
[10:16:28 CDT(-0500)] <serac> np
[10:17:01 CDT(-0500)] <wgthom> another is CAS as enterprise WebSSO where the app sessions are more independent of CAS
[10:18:05 CDT(-0500)] <ries> baby steps…. baby steps….
[10:32:26 CDT(-0500)] <ries> is it required to use the fqdn? I currently only have IP addresses for these servers..
[10:37:26 CDT(-0500)] <wgthom> yes for ssl to work.
[10:39:23 CDT(-0500)] <wgthom> you could try putting entries in /etc/hosts or where that file is on windows
[10:50:24 CDT(-0500)] <ries> wgthom: I am currently testing without SSL… that shouldn't matter, right?
[10:54:05 CDT(-0500)] <wgthom> SSL is required for CAS. i woudn't test without it
[10:54:12 CDT(-0500)] <serac> +1
[10:55:07 CDT(-0500)] <ries> wgthom: for production we will use it… but so far I don't see CAS complaining without SSL
[10:55:53 CDT(-0500)] <serac> SSO will not work without SSL. (by default anyway)
[10:56:02 CDT(-0500)] <ries> ic ic...
[10:56:44 CDT(-0500)] <ries> Since I didn't see anything in the log file I thought I should have been fine
[12:57:03 CDT(-0500)] <apetro> ries, what version of CAS? Latest should have nagged you on login screen that SSO would not work w/o SSL
[13:00:40 CDT(-0500)] <apetro> Checking in.
[13:00:46 CDT(-0500)] <serac> My clock reads 1400. It's dev chat time.
[13:01:04 CDT(-0500)] <wgthom> hola amigos
[13:01:45 CDT(-0500)] <serac> ¡Hola!
[13:01:54 CDT(-0500)] <apetro> Agenda bash?
[13:02:03 CDT(-0500)] <serac> I have nothing.
[13:02:11 CDT(-0500)] <serac> Maybe some questions on status.
[13:02:21 CDT(-0500)] <ries> apetro: I am using 3.4.2
[13:02:33 CDT(-0500)] <serac> e.g. 3.4.11 release timeframe
[13:02:38 CDT(-0500)] <serac> Markdown progress
[13:02:48 CDT(-0500)] <serac> unconference
[13:04:13 CDT(-0500)] <apetro> Ok. 3.4.11 release planning, CAS manual, UnConference. What else?
[13:05:09 CDT(-0500)] <apetro> Roadmap and 3.5 strike that 4.0 development and release planning?
[13:06:09 CDT(-0500)] <serac> Sure.
[13:06:12 CDT(-0500)] <apetro> Sounds like an agenda, at least enough to get started on.
[13:06:31 CDT(-0500)] <serac> On 3.4.11...
[13:06:46 CDT(-0500)] <apetro> I see Scott addressed the default Order for the match-all default services.
[13:06:47 CDT(-0500)] <serac> I think we've presently got enough for a point release.
[13:07:01 CDT(-0500)] <serac> He hit a ton of Jira issues this weekend.
[13:07:38 CDT(-0500)] <serac> I merge in the non-printing character fix yesterday.
[13:07:51 CDT(-0500)] <apetro> I think this is the relevant JIRA report: https://issues.jasig.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CAS+AND+fixVersion+%3D+%223.4.11%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESC&mode=hide
[13:08:14 CDT(-0500)] <wgthom>
[13:08:50 CDT(-0500)] <wgthom> should changing the default behavior of match-all trigger a 3.5?
[13:09:16 CDT(-0500)] <apetro> wgthom, I wouldn't think so. It's not a behavior change, it's a default data set change.
[13:09:18 CDT(-0500)] <serac> I don't think so.
[13:09:47 CDT(-0500)] <wgthom> a default data set change…that changes default behavior?
[13:09:59 CDT(-0500)] <apetro> Should make it slightly less annoying to folks trying out the in-memory services registry, or naively seeding their JPA registry going with the data they saw in the default configu, which is an understandable thing to do.
[13:10:17 CDT(-0500)] <serac> I think it's a good change.
[13:10:37 CDT(-0500)] <apetro> wgthom, that's my understanding of the change that was requested in JIRA, but I haven't reviewed the actual commit so I'm not sure how the issue was addressed
[13:10:37 CDT(-0500)] <serac> The intention is that these are catch-all entries that should naturally be at the end.
[13:10:43 CDT(-0500)] <apetro> in seconds I will know, though – looking for the commit
[13:10:54 CDT(-0500)] <serac> I reviewed the commit – looks good.
[13:11:07 CDT(-0500)] <serac> Just set order=<very high number> on default entries.
[13:11:32 CDT(-0500)] <apetro> precisely. Currently, a deployer trying out CAS has like a 50-50 chance that an entry they add to the default registry will do anything, because they're not going to immediately have a robust strategy for using Order field.
[13:11:46 CDT(-0500)] <serac> We've been doing this for ages here @ VT.
[13:11:50 CDT(-0500)] <apetro> and with this fix, if they don't try very hard, they'll get the effect they were looking for when they add a new entry.
[13:12:17 CDT(-0500)] <serac> I think it's a non-issue.
[13:12:20 CDT(-0500)] <apetro> yup. I still like the idea of making Order unnecessary through more sophisticated matching strategy, but this is fine to make the default less annoying.
[13:12:21 CDT(-0500)] <wgthom> how will if effect someone with 3.4.10 who does a mvn clean deploy?
[13:12:24 CDT(-0500)] <serac> w/r/t change in behavior
[13:12:46 CDT(-0500)] <apetro> it won't affect any existing deployers, since 100% of existing deployers will have their own deployerConfigContext.xml
[13:12:50 CDT(-0500)] <serac> I'd imagine it would have no effect in most cases.
[13:12:58 CDT(-0500)] <wgthom> ok
[13:13:01 CDT(-0500)] <serac> Right, they don't use the defaults anyway.
[13:13:14 CDT(-0500)] <apetro> and the changed default data by itself has exactly the same behavior as before
[13:13:26 CDT(-0500)] <wgthom> got it
[13:13:30 CDT(-0500)] <apetro> it's just better set up to accomodate a deployer adding an additional service registration.
[13:13:39 CDT(-0500)] <apetro> yup. Very minor polish.
[13:13:56 CDT(-0500)] <apetro> this one, for anyone reviewing the log : https://issues.jasig.org/browse/CAS-1007
[13:13:58 CDT(-0500)] <apetro> let's move on
[13:14:12 CDT(-0500)] <apetro> so 3.4.11 release. Doing the RC first this time?
[13:14:34 CDT(-0500)] <serac> We should just get in the habit.
[13:14:57 CDT(-0500)] <apetro> k, 3.4.11 RC and then GA when everyone loves it.
[13:14:58 CDT(-0500)] <wgthom> big +1 for RC
[13:15:07 CDT(-0500)] <apetro> nice to get a release out that addresses that non-printing-characters-thingy
[13:15:14 CDT(-0500)] <serac> Indeed.
[13:15:31 CDT(-0500)] <serac> Want to demonstrate prompt response.
[13:15:54 CDT(-0500)] <apetro> Cool.
[13:16:05 CDT(-0500)] <apetro> Who's doing what work to cut this 3.4.11 RC on what timeline?
[13:16:05 CDT(-0500)] <serac> battags – you following?
[13:16:35 CDT(-0500)] <serac> We need to clarify whether anything special is needed for the PGP key used to sign maven artifacts in Maven central.
[13:16:53 CDT(-0500)] <serac> I don't think so, but wanted battags to confirm.
[13:17:02 CDT(-0500)] <serac> If there's no special requirement, anyone can do the release.
[13:17:34 CDT(-0500)] <serac> I'd really like some "formal" discussion on any committer doing release.
[13:18:02 CDT(-0500)] <serac> If nothing else it's a departure from our practice of past several years with lead dev doing them (aka battags).
[13:18:40 CDT(-0500)] <serac> Seems like the "right thing" to at least make a proposal for this change and then vote. I'd meant to do this in the past weeks, but we know about good intentions.
[13:19:37 CDT(-0500)] <apetro> eh. I don't think it's a formal departure. Any committer should be able to propose doing and, with the support of the committers, execute on, doing a release.
[13:19:42 CDT(-0500)] <serac> The proposal will be tit for tat: add release voting and allow any active committer to release. The release voting is a check/balance on releasing.
[13:19:54 CDT(-0500)] <serac> Andrew: it's a departure from what we've been doing.
[13:19:57 CDT(-0500)] <serac> it's a simple fact
[13:20:16 CDT(-0500)] <serac> I'm just saying we should all agree on this change. It's no big deal.
[13:20:26 CDT(-0500)] <apetro> sure. but not a departure from what we should have been doing. Discuss away, vote away, but I don't think it's an issue. Agreed it's no big deal.
[13:20:26 CDT(-0500)] <serac> Just a change in process.
[13:21:19 CDT(-0500)] <apetro> so, pending formal discussion of any committer doing this release, serac, you cutting this RC?
[13:21:21 CDT(-0500)] <serac> I'll send that out this weekend, then hopefully we can cut the RC next week.
[13:21:24 CDT(-0500)] <wgthom> so we are talking abotu procedural issues
[13:21:26 CDT(-0500)] <wgthom> http://www.apache.org/foundation/voting.html
[13:21:38 CDT(-0500)] <serac> We all know how voting works.
[13:22:05 CDT(-0500)] <wgthom> is there anyone against sharing the release cutting load?
[13:22:26 CDT(-0500)] <serac> I don't believe so, but process decisions are made on cas-dev.
[13:24:05 CDT(-0500)] <wgthom> just pointing out if there's no objections then a vote isn't really needed
[13:24:14 CDT(-0500)] <serac> None of us speaks for another.
[13:24:17 CDT(-0500)] <serac> Scott's not here.
[13:24:50 CDT(-0500)] <serac> The dev list is a good way to allow opinions and input from folks that aren't here now, including but not limited to Scott.
[13:24:57 CDT(-0500)] <wgthom> sure
[13:24:59 CDT(-0500)] <wgthom> of course
[13:25:00 CDT(-0500)] <serac> This is a fairly new channel, after all.
[13:25:16 CDT(-0500)] <wgthom> wasn't looking for a roll call…
[13:25:17 CDT(-0500)] <serac> Anyway, let's move on.
[13:25:23 CDT(-0500)] <apetro> sounds like a fine thing to discuss on cas-dev, maybe more with the discussing and less with the voting.
[13:25:25 CDT(-0500)] <serac> RC next week regardless.
[13:25:45 CDT(-0500)] <apetro> alright. 3.4.11 RC next week, ideally with serac doing it thereby demonstrating that multiple committers can do releases.
[13:25:56 CDT(-0500)] <serac> Sounds good.
[13:26:01 CDT(-0500)] <apetro> Markdown progress?
[13:26:07 CDT(-0500)] <serac> Yeah, how's it going?
[13:26:21 CDT(-0500)] <wgthom> don't we need Scott to vote on the release? lol
[13:26:22 CDT(-0500)] <apetro> it's here https://github.com/apetro/CAS-Documentation
[13:27:00 CDT(-0500)] <apetro> no one's forked and pull requested yet, which in most ways is too bad because it would demonstrate folks trying out the markdown format and determining if it would meet documentation formatting needs.
[13:27:23 CDT(-0500)] <serac> I'll try to at least review it next week if not fork.
[13:27:33 CDT(-0500)] <apetro> I haven't had time to circle back and merge in CAS SAML protocol support documentation, something I'd like to do since I had to dig into that stuff recently for a support case
[13:27:47 CDT(-0500)] <apetro> I still think it has more going for it than does DocBook, on balance
[13:27:59 CDT(-0500)] <serac> Do you have a reasonable solution for pdf?
[13:28:12 CDT(-0500)] <apetro> nope. I have an unreasonable solution for PDF generation.
[13:28:17 CDT(-0500)] <serac> haha
[13:28:22 CDT(-0500)] <serac> What about build integration?
[13:28:33 CDT(-0500)] <serac> i.e. generate docs as part of build
[13:28:39 CDT(-0500)] <apetro> it generates a PDF for me, example here: http://cloud.github.com/downloads/apetro/CAS-Documentation/casmanual.en.pdf
[13:29:10 CDT(-0500)] <apetro> no build integration. For one thing, the build is unreasonable, so it's not going to work in the generic Maven builder case anyway
[13:29:18 CDT(-0500)] <apetro> but even if it did, there's no Maven integration to fire it off
[13:29:46 CDT(-0500)] <serac> How do you do styling, graphics, etc?
[13:29:56 CDT(-0500)] <serac> The pdf is very, how do you say, white?
[13:29:56 CDT(-0500)] <apetro> laid out some of these considerations in that thread on cas-dev
[13:30:03 CDT(-0500)] <apetro> whitespace is good for the soul
[13:30:15 CDT(-0500)] <serac> In reasonable measure, sure.
[13:30:21 CDT(-0500)] <apetro> it's a very minimal syntax.
[13:30:23 CDT(-0500)] <serac> But I'm going snowblind here 
[13:30:39 CDT(-0500)] <serac> Ok, I see graphics now.
[13:30:59 CDT(-0500)] <apetro> Yes, you can do insertion of images, as demonstrated in PDF. They go here: https://github.com/apetro/CAS-Documentation/tree/master/media and are referenced via a
| Wiki Markup |
|---|
!image! |
...