jasig-cas IRC Logs-2011-10-13

[08:02:48 CDT(-0500)] <kickehy> mornin'

[08:04:48 CDT(-0500)] <apetro> mornin', kickehy

[08:26:21 CDT(-0500)] <kickehy> atilling: thanks for that tomcat certificate link the other day, I got that working properly

[08:26:39 CDT(-0500)] <atilling> great glad to be a help

[08:28:04 CDT(-0500)] <kickehy> now the last thing to tackle is ldaps

[08:28:25 CDT(-0500)] <atilling> ok, that should be fairly easy at this point

[08:28:53 CDT(-0500)] <atilling> you have a cpoy of the cert from the ldap server?

[08:29:13 CDT(-0500)] <kickehy> yes, in DER format

[08:33:54 CDT(-0500)] <atilling> ok, you should be able to use key tool to add that cert to that cacerts file inside your JRE

[08:35:45 CDT(-0500)] <kickehy> and that's it?

[08:36:20 CDT(-0500)] <atilling> should be

[08:36:37 CDT(-0500)] <kickehy> keytool import -keystore $JAVA_HOME/jre/lib/security/cacerts -file tmp/incommon-root-cert.der -alias incommon <--that's in the SSL troubleshooting guide, i assume you don't use the -trustcacerts switch

[08:36:42 CDT(-0500)] <atilling> Once that cert is in cacerts all your java apps should trust it

[08:37:14 CDT(-0500)] <atilling> that looks right to me

[08:38:26 CDT(-0500)] <atilling> If your LDAPS cert is signed by a CA that java trusts then you don't even need to that

[08:38:53 CDT(-0500)] <kickehy> ooo so it would be better to import the CA's certificate?

[08:39:28 CDT(-0500)] <atilling> both are options, CA would be more reliable

[08:43:12 CDT(-0500)] <kickehy> hmmm

[08:43:26 CDT(-0500)] <kickehy> sslhandshakeexception

[08:46:55 CDT(-0500)] <kickehy> PKIX path building failed <--that same error as in the ssl troubleshooting guide

[08:47:12 CDT(-0500)] <atilling> hmm, that is odd

[08:47:32 CDT(-0500)] <atilling> well try adding the server's cert then directly

[08:48:37 CDT(-0500)] <atilling> also if your debuging the SSL stack you should see that path for the trust file it's using and the list of trusted certs

[08:49:44 CDT(-0500)] <kickehy> where do you change the option to debug ssl?

[08:53:44 CDT(-0500)] <atilling> in your java options

[08:53:46 CDT(-0500)] <kickehy> could it be because my java_home variable is set to C:\Program Files (x86)\Java\jdk1.6.0_25 rather than C:\Program Files (x86)\Java\jdk1.6.0_25\jre ?

[08:54:08 CDT(-0500)] <atilling> very likely

[08:54:50 CDT(-0500)] <atilling> you then want to add the cert to the cacerts in that jdk

[08:55:40 CDT(-0500)] <kickehy> or...

[08:55:42 CDT(-0500)] <atilling> but to debug ssl add -Djavax.net.debug=ssl to your tomcat start up

[08:57:31 CDT(-0500)] <kickehy> or! does java use the jre6 folder rather than the jdk1.6.0_25 folder?

[08:57:36 CDT(-0500)] <kickehy> cus i have two

[08:58:14 CDT(-0500)] <atilling> you probably have an environment variable set during your tomcat startup for Java_home

[08:58:29 CDT(-0500)] <atilling> That's the java and cacert your using

[08:59:14 CDT(-0500)] <atilling> as I said if you put that -Djavax.net.debug=ssl in your setenv catalina_opts you'll see a lot of debug

[08:59:37 CDT(-0500)] <kickehy> mmmk

[08:59:51 CDT(-0500)] <atilling> but even without that your catalina.out file should show the JAVA_HOME at every server startup

[09:23:04 CDT(-0500)] <kickehy> i must be blind because i don't see a catalina.out file in the tomcat logs

[09:25:31 CDT(-0500)] <atilling> very odd

[09:25:42 CDT(-0500)] <atilling> what files do you have?

[09:26:45 CDT(-0500)] <kickehy> ok, it is pointing to the jre6 folder, i just added my CA's cert to the cacerts file within the jre6 folder and i was able to login successfully

[09:27:18 CDT(-0500)] <atilling> nice

[09:27:24 CDT(-0500)] <kickehy> i'll just go with that then

[09:27:33 CDT(-0500)] <kickehy> i mean, it makes sense

[09:27:39 CDT(-0500)] <kickehy> to not use the jdk folder

[09:27:43 CDT(-0500)] <atilling> yup it does

[09:27:47 CDT(-0500)] <kickehy> and use the actual java application folder

[09:28:06 CDT(-0500)] <kickehy> i think i was thrown off when i set the %JAVA_HOME% variable

[09:28:13 CDT(-0500)] <kickehy> so i just naturally used that folder

[09:28:13 CDT(-0500)] <atilling> your maven needs the jdk though so don't remove it

[09:28:24 CDT(-0500)] <kickehy> mmmk

[09:28:52 CDT(-0500)] <atilling> so your CAS install 100% now? Working as needed/intended?

[09:29:05 CDT(-0500)] <kickehy> i think so, i have ssl setup for tomcat and ldaps

[09:29:20 CDT(-0500)] <kickehy> i just don't have an application to test with it yet (tongue)

[09:29:48 CDT(-0500)] <atilling> you have a web server with php?

[09:30:32 CDT(-0500)] <kickehy> our moodle test server

[09:30:35 CDT(-0500)] <kickehy> that should work

[09:31:49 CDT(-0500)] <kickehy> oooo that's actually a great idea in general

[09:31:56 CDT(-0500)] <kickehy> to get cas to function with moodle

[09:32:03 CDT(-0500)] <kickehy> then we wouldn't have to create accounts

[09:33:04 CDT(-0500)] <atilling> That's the solution we use

[09:35:11 CDT(-0500)] <kickehy> granted, sso kind of scares me, but there's definately a couple applications that could use it that would make our lives easier

[09:35:37 CDT(-0500)] <kickehy> but then again, the average user uses the same password for everything anyways

[09:35:48 CDT(-0500)] <atilling> once you get the hang of it the trust is higher and you'll love it

[09:36:12 CDT(-0500)] <atilling> SSO they only have one password, and it's ONLY stored one place

[09:36:32 CDT(-0500)] <atilling> all those other apps don't even know what password the user used

[09:37:05 CDT(-0500)] <atilling> someone could hack your moodle all day and not get access to a single user's password

[09:38:11 CDT(-0500)] <kickehy> and in my case, this would be our AD server

[09:38:41 CDT(-0500)] <atilling> right, and by design AD alot more secure then moodle

[09:38:50 CDT(-0500)] <kickehy> heh

[09:41:21 CDT(-0500)] <kickehy> is there really anything else i should setup inside of cas?

[09:41:42 CDT(-0500)] <kickehy> i just assume logging in with ldap will solve most of my issues

[09:42:18 CDT(-0500)] <atilling> best practices - login throteling, service management

[09:42:54 CDT(-0500)] <atilling> I like the enforcement of expiration policies - but that might be because I wrote it

[09:43:26 CDT(-0500)] <kickehy> like a cas session timeout?

[09:44:16 CDT(-0500)] <atilling> no expiration policies, by default CAS just checks if password is valid or not - that's it

[09:44:26 CDT(-0500)] <atilling> if it's not valid it doesn't care why

[09:44:47 CDT(-0500)] <kickehy> oh i see

[09:44:47 CDT(-0500)] <atilling> and if your password is going to expire in an hr it ignores that too

[09:44:59 CDT(-0500)] <foxnesn1> morning

[09:45:04 CDT(-0500)] <kickehy> foxnesn1: mornin'

[09:45:16 CDT(-0500)] <foxnesn1> im still working on getting cas to auth with ldap

[09:45:22 CDT(-0500)] <foxnesn1> i tried fastbind and still no go

[09:45:26 CDT(-0500)] <atilling> the password expire policies allow you to do something about those situations

[09:45:41 CDT(-0500)] <atilling> like a warning that you password will expire in 5 days

[09:45:42 CDT(-0500)] <kickehy> atilling: i suppose you don't use group policy?

[09:45:52 CDT(-0500)] <atilling> we don't no

[09:46:27 CDT(-0500)] <atilling> foxnesn1: how are the error logs looking?

[09:46:44 CDT(-0500)] <foxnesn1> well first, i cannot get the error logs to stay in debug mode

[09:46:55 CDT(-0500)] <kickehy> atilling: thanks for all your help

[09:46:57 CDT(-0500)] <foxnesn1> i change them in log4j.xml in my workspace

[09:47:03 CDT(-0500)] <foxnesn1> then i mvn clean package

[09:47:17 CDT(-0500)] <foxnesn1> and then i go and check log4j in the actual deployed area in tomcat webapps

[09:47:23 CDT(-0500)] <foxnesn1> and it still reads WARN

[09:47:31 CDT(-0500)] <kickehy> atilling: and do you think it would be good if i created a wiki on my experiences, because i don't think there's a solid windows one out there

[09:47:38 CDT(-0500)] <atilling> you should be updating log4j in src/main/webapp/WEB-INF/classes

[09:47:45 CDT(-0500)] <kickehy> and I don't think i'd mind writing that up at some point

[09:47:48 CDT(-0500)] <foxnesn1> o

[09:47:54 CDT(-0500)] <foxnesn1> kickehy: do it!

[09:48:04 CDT(-0500)] <foxnesn1> im definitely going to write something up when im done with this

[09:48:11 CDT(-0500)] <foxnesn1> i will have to anyway to document it

[09:48:21 CDT(-0500)] <kickehy> heh same

[09:48:25 CDT(-0500)] <kickehy> that's my next step

[09:48:49 CDT(-0500)] <atilling> If either of you would like, send me how you would change the current wiki entry, I have the rights to make wiki updates

[09:49:46 CDT(-0500)] <atilling> I would rather make the current entry "right" then to see another created

[09:51:01 CDT(-0500)] <foxnesn1> when im setting the ldap url do i have to include :389 or :636 ?

[09:51:10 CDT(-0500)] <foxnesn1> or does cas assume ldap = 389 and ldaps = 636

[09:51:26 CDT(-0500)] <atilling> shouldn't need to, but not a bad practice

[09:51:39 CDT(-0500)] <atilling> you only need to if using a nonstandard port

[09:53:18 CDT(-0500)] <foxnesn1> and since im running without ssl it is normal to get the warning message in my browser about the cert no being genuine?

[09:53:42 CDT(-0500)] <kickehy> atilling: i'll copy everything into a doc and edit it, then show you my changes

[09:56:40 CDT(-0500)] <atilling> correct

[09:57:14 CDT(-0500)] <foxnesn1> logs look good

[09:57:24 CDT(-0500)] <atilling> untill you get a real cert on the server the login page willl give you a certificate warning in the browser

[09:57:39 CDT(-0500)] <foxnesn1> just says fastbindldapauthenticationhandler faild to auth the user/pass i put in using sAMAccountName

[09:57:52 CDT(-0500)] <foxnesn1> which is expected since it cant auth me

[09:59:47 CDT(-0500)] <foxnesn1> i can connect to the ldap using the same credentials using our password self service program and if i want to browse the ldap i can connect using the active directory explorer

[09:59:53 CDT(-0500)] <foxnesn1> so i must be missing something here

[10:03:00 CDT(-0500)] <atilling> you still have <bean id="HTTPCredentialtoPrincipalResolver" class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" /> in your config right?

[10:09:04 CDT(-0500)] <foxnesn1> yea

[10:09:14 CDT(-0500)] <foxnesn1> how can i tell fastbind to search in CN=Users

[10:09:28 CDT(-0500)] <foxnesn1> right now i just point it at the ldap and tell it to search by sAMAccountName

[10:09:31 CDT(-0500)] <foxnesn1> clearly that is not working

[10:09:39 CDT(-0500)] <foxnesn1> but all the users are in Users

[10:09:47 CDT(-0500)] <atilling> for fastbind try changing filter to value="%u@mycoll.edu" />

[10:10:21 CDT(-0500)] <atilling> though odviously with your email format

[10:11:44 CDT(-0500)] <foxnesn1> that's userprincipal name

[10:12:17 CDT(-0500)] <atilling> ok, but most times with AD that's what it expects for username

[10:12:28 CDT(-0500)] <foxnesn1> like i want it to search cn=users,dc=easyrhino,dc=lcl

[10:12:43 CDT(-0500)] <foxnesn1> but search based on sAMAccountName

[10:12:55 CDT(-0500)] <atilling> fastbind doesn't do a search

[10:13:02 CDT(-0500)] <atilling> so you can't specify

[10:13:21 CDT(-0500)] <atilling> fastbind just trys to bind to the ldap as the user

[10:13:35 CDT(-0500)] <foxnesn1> but how does it know where to look then?

[10:13:46 CDT(-0500)] <atilling> try the filter as %u@easyrhino.lcl

[10:13:55 CDT(-0500)] <foxnesn1> k

[10:14:05 CDT(-0500)] <atilling> it's the normal AD login function

[10:14:42 CDT(-0500)] <atilling> if using bindAuth the userDN should have been something like administrator@easyrhino.lcl

[10:15:05 CDT(-0500)] <atilling> or ldapro@easyrhino.lcl

[10:16:08 CDT(-0500)] <foxnesn1> <bean class="org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler" > <property name="filter" value="%u=easyrhino.lcl" />

[10:16:12 CDT(-0500)] <foxnesn1> <property name="contextSource" ref="contextSource" />

[10:16:15 CDT(-0500)] <foxnesn1> <property name="ignorePartialResultException" value="yes" />

[10:16:18 CDT(-0500)] <foxnesn1> that is the bean and the values

[10:16:42 CDT(-0500)] <atilling> Looks good

[10:16:58 CDT(-0500)] <foxnesn1> yea still fails

[10:17:38 CDT(-0500)] <atilling> contextSource is what?

[10:18:03 CDT(-0500)] <atilling> actually do another pastie of the config

[10:18:46 CDT(-0500)] <foxnesn1> ok

[10:18:48 CDT(-0500)] <foxnesn1> logs shows

[10:18:51 CDT(-0500)] <foxnesn1> <Performing LDAP bind with credential: seth=easyrhino.lcl>

[10:19:02 CDT(-0500)] <foxnesn1> which obviously doesnt look right

[10:19:36 CDT(-0500)] <atilling> <property name="filter" value="%u=easyrhino.lcl" /> should be <property name="filter" value="%u@easyrhino.lcl" />

[10:19:50 CDT(-0500)] <atilling> @ not =

[10:20:23 CDT(-0500)] <foxnesn1> http://pastie.org/2689420

[10:21:10 CDT(-0500)] <atilling> yeah try replacing the = with the @

[10:21:18 CDT(-0500)] <atilling> I think that's all you need now

[10:26:49 CDT(-0500)] <foxnesn1> hrm didnt deploy

[10:26:54 CDT(-0500)] <foxnesn1> im looking through the logs as to why

[10:27:20 CDT(-0500)] <atilling> so the property line you have now is? <property name="filter" value="%u@easyrhino.lcl" />

[10:27:37 CDT(-0500)] <atilling> correct?

[10:28:27 CDT(-0500)] <foxnesn1> yup

[10:29:53 CDT(-0500)] <atilling> ok, not sure why that wouldn't deploy - looks all ok to me now

[10:29:58 CDT(-0500)] <atilling> brb

[10:33:29 CDT(-0500)] <foxnesn1> it worked!

[10:33:53 CDT(-0500)] * foxnesn1 does a dance

[10:35:37 CDT(-0500)] <foxnesn1> i owe you a beer

[10:36:33 CDT(-0500)] <foxnesn1> brb

[10:45:11 CDT(-0500)] <kickehy> looks like they just released java 7

[10:57:22 CDT(-0500)] <atilling> back

[11:00:54 CDT(-0500)] <atilling> interesting, not going to jump to java 7 right now though (smile)

[11:08:09 CDT(-0500)] <atilling> foxnesn1: Glad it's working for you now - I'm more of a Rum & Coke person (smile)

[11:10:18 CDT(-0500)] <foxnesn1> consider it done lol

[11:15:01 CDT(-0500)] <foxnesn1> now that i know it works i can break it

[11:15:19 CDT(-0500)] <atilling> That's the spirt (smile)

[11:15:29 CDT(-0500)] <foxnesn1> because i believe programs like Banner use bindauth

[11:15:30 CDT(-0500)] <foxnesn1> not fastbind

[11:17:44 CDT(-0500)] <atilling> definately then need attributes

[11:21:51 CDT(-0500)] <foxnesn1> well i know right now that the CAS in sungard's luminus program uses bindauth because we have a separate user/pass for it to search

[11:21:59 CDT(-0500)] <foxnesn1> should be interesting

[11:22:34 CDT(-0500)] <atilling> LP4 or LP5?

[11:22:45 CDT(-0500)] <foxnesn1> 4 i believe

[11:22:57 CDT(-0500)] <foxnesn1> we never upgraded because we hate luminus lol

[11:23:08 CDT(-0500)] <foxnesn1> which is what is spurring us rolling our own HA CAS

[11:23:08 CDT(-0500)] <atilling> right and LP4 has it's own LDAP servrer

[11:23:35 CDT(-0500)] <foxnesn1> well all our users auth against our AD

[11:24:01 CDT(-0500)] <atilling> We haven't gone LP5 yet - for a lot of reasons - But we are using Liferay 5 and we were part of the LP5 fouc group

[11:24:13 CDT(-0500)] <foxnesn1> cool

[11:24:20 CDT(-0500)] <atilling> LP5 / Liferay MILES ahead of LP4

[11:24:32 CDT(-0500)] <atilling> totally different beast entirely

[11:24:34 CDT(-0500)] <foxnesn1> good to know

[11:24:59 CDT(-0500)] <atilling> Liferay is a great product, hand down

[11:25:32 CDT(-0500)] <atilling> LP5 IS liferay that they plugged some Sungard specific modules into

[11:25:43 CDT(-0500)] <foxnesn1> that's what ive heard

[11:25:52 CDT(-0500)] <atilling> this time sungard is doing it mostly right

[11:26:06 CDT(-0500)] <foxnesn1> i wonder if my boss knows that lol

[11:26:16 CDT(-0500)] <atilling> with Luminis pre 5 they started with uPortal and then gutted it

[11:26:20 CDT(-0500)] <foxnesn1> i think tho it has been decided to move the portal to a new vendor

[11:26:49 CDT(-0500)] <atilling> and then they built thier own portal inside the corpse of uPortal

[11:26:51 CDT(-0500)] <foxnesn1> im not really sure of what upper management is really thinking or how they explain the move

[11:27:16 CDT(-0500)] <atilling> This time they started with Liferay and they left it alone

[11:27:52 CDT(-0500)] <atilling> the portal is still 100% liferay and "luminis" just delivers content through it

[11:28:26 CDT(-0500)] <atilling> so as liferay updates/evolves lp5 will

[11:28:59 CDT(-0500)] <atilling> with their old method when uPortal updated luminis was just completely left in the dust

[11:28:59 CDT(-0500)] <foxnesn1> but hasnt the issue been sungard does a poor job keeping up uwith the updates?

[11:29:51 CDT(-0500)] <atilling> right it has, so the intent is that you can update your portal as Liferay updates

[11:29:57 CDT(-0500)] <atilling> not as sungard updates

[11:30:31 CDT(-0500)] <foxnesn1> oh

[11:30:35 CDT(-0500)] <foxnesn1> well that is nice

[11:31:43 CDT(-0500)] <atilling> as I said our portal is already liferay, we just aren't LP5 due to issues on our banner side

[11:32:06 CDT(-0500)] <atilling> but LP5 is 100% open source technologies

[11:32:23 CDT(-0500)] <atilling> Java, Hibernate, spring, JSR-286 etc

[11:33:06 CDT(-0500)] <atilling> in theroy (not yet supported) you could deploy any JSR-286 compliant portal and tie in LP5 content

[11:33:39 CDT(-0500)] <atilling> in truth LP5 doesn't even live in the portal

[11:34:08 CDT(-0500)] <atilling> it's an almost plain vaninal liferay portal and the portlets are lp5

[11:42:19 CDT(-0500)] * apetro wishes Sungard would simply produce and vend standards-compliant JSR-286 portlets so they would be runnable in other portals as well.

[11:42:55 CDT(-0500)] <atilling> That is/was the objective of LP5

[11:44:18 CDT(-0500)] <foxnesn1> hrm

[13:12:31 CDT(-0500)] <foxnesn1> so if i have cas/login set up as a gateway to a portal is there a way to forward the authenticated user to the portal?

[13:13:03 CDT(-0500)] <foxnesn1> or would be something like point them to the portal which would obviously redirect to cas/login

[13:13:26 CDT(-0500)] <foxnesn1> so cas/login isnt necessarily a "gateway"

[13:39:04 CDT(-0500)] <atilling> the portal should use CAS for auth

[13:39:42 CDT(-0500)] <atilling> so when a user hits a portal page if the page isn't public is checks CAS for auth

[13:40:49 CDT(-0500)] <atilling> CAS then passes back a service ticket if user is logged in or presents the user with a login page if not

[13:41:23 CDT(-0500)] <atilling> the login page will have a service parameter that tells where the user goes back to when login is complete

[13:43:40 CDT(-0500)] <foxnesn1> right

[13:43:55 CDT(-0500)] <foxnesn1> but lets say we want everyone to go to the /cas/login first

[13:44:03 CDT(-0500)] <foxnesn1> sure, they COULD go to the portal directly using a url

[13:44:10 CDT(-0500)] <foxnesn1> which would then bring them to the cas login

[13:44:26 CDT(-0500)] <foxnesn1> but instead we want to direct them to the cas/login as our gateway

[13:44:38 CDT(-0500)] <foxnesn1> could we then after auth tell cas to forward to the portal?

[13:45:13 CDT(-0500)] <atilling> you could add something to loginWebFlow

[13:45:28 CDT(-0500)] <atilling> something that set a default service when one isn't passed

[13:46:01 CDT(-0500)] <atilling> but if your portal is 100% secure they will hit the cas login page right off the bat

[13:46:11 CDT(-0500)] <atilling> they won't know they hit the portal first

[13:46:50 CDT(-0500)] <atilling> Try http://camelweb.conncoll.edu

[14:30:44 CDT(-0500)] <apetro> if you send a user to /cas/login?service=URL , CAS will redirect to the URL with a valid service ticket if the user already has an SSO session

[14:30:54 CDT(-0500)] <apetro> if they don't have an SSO session, they'll have to log in first

[14:31:01 CDT(-0500)] <apetro> so redirect back from CAS is immediate when it can be

[14:31:27 CDT(-0500)] <apetro> CAS also has a gateway=true optional parameter on /cas/login, such that if you want CAS to redirect back without a ticket if it can't rely on an existing SSO session, it will do that.

[15:39:07 CDT(-0500)] <foxnesn1> ahh i see

[15:39:35 CDT(-0500)] <foxnesn1> so camelweb.conncoll.edu redirects automaticall to cas/login since there is no ticket