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