[11:25:54 CDT(-0500)] <jwennmacher> I'm working on UP-3689 to basically allow you to access an URL that requires authentication and display the page after authentication is complete without having to craft a 'deep link' url that includes the refUrl parameter.
[11:27:01 CDT(-0500)] <jwennmacher> On Friday I started to try and figure out where uPortal determines authentication is required and redirect to /Login. I didn't find it. Does anyone happen to know how/where uPortal determines the user must be authenticated to access an URL?
[11:27:29 CDT(-0500)] <EricDalquist> it doesn't
[11:27:37 CDT(-0500)] <EricDalquist> well
[11:27:38 CDT(-0500)] <EricDalquist> maybe
[11:27:50 CDT(-0500)] <EricDalquist> sorry
[11:27:52 CDT(-0500)] <EricDalquist> I missread that
[11:27:54 CDT(-0500)] <EricDalquist> it does
[11:28:03 CDT(-0500)] <EricDalquist> and it already captures the reference url I bleive
[11:28:05 CDT(-0500)] <EricDalquist> let me find it ...
[11:30:03 CDT(-0500)] <EricDalquist> org.jasig.portal.url.RequireValidSessionFilter
[11:30:25 CDT(-0500)] <EricDalquist> note that the filter already captures the current url
[11:30:46 CDT(-0500)] <EricDalquist> and sets it as the refUrl when redirecting to /Login
[11:30:56 CDT(-0500)] <EricDalquist> and after /Login runs the portal redirects the user back to that url
[11:32:38 CDT(-0500)] <jwennmacher> hmm... thanks for pointing that out. So that probably works for a local login but probably not CAS.
[11:32:47 CDT(-0500)] <EricDalquist> it works for shib too
[11:33:01 CDT(-0500)] <EricDalquist> the trick is your SSO system needs to be smart enough to carry that URL along
[11:33:34 CDT(-0500)] <EricDalquist> I'm not familiar with CAS but I'm wondering if you just need to somehow get CAS to "know" about the refUrl
[11:35:26 CDT(-0500)] <jwennmacher> What you are suggesting is sounds possible. If we can encode the refUrl on the end of the service url I think it will be passed along. That's what the docs on the Deep Linking page suggest. https://wiki.jasig.org/pages/viewpage.action?pageId=53610142
[11:36:03 CDT(-0500)] <EricDalquist> so it might be an issue of figuring out how to tell the "authentication" code what the refUrl is
[11:36:15 CDT(-0500)] <EricDalquist> or just biting bullet and switching uPortal to spring security 
[11:36:20 CDT(-0500)] <jwennmacher> Unfortunately that involves some modifications to the CAS that I'll have to take a look at. I'm not as fond of that idea though but I'll look into it.
[11:36:41 CDT(-0500)] <EricDalquist> you could try setting the refUrl as a session parameter
[11:36:43 CDT(-0500)] <jwennmacher> I want to switch to Spring Security but the time allotment doesn't accommodate that. 
[11:36:54 CDT(-0500)] <EricDalquist> that might work
[11:37:08 CDT(-0500)] <EricDalquist> though you'll have to be careful to grab it out before the session gets invalidated during auth
[11:37:20 CDT(-0500)] <jwennmacher> Placing the ref url in session has been my original plan. That's the way spring security does it as I recall.
[11:37:42 CDT(-0500)] <jwennmacher> Drew mentioned something about session getting invalidated during auth. Do you know how that happens? I haven't looked for that yet.
[11:37:57 CDT(-0500)] <EricDalquist> I think it happens in LoginController
[11:39:02 CDT(-0500)] <EricDalquist> hrm
[11:39:03 CDT(-0500)] <EricDalquist> maybe not
[11:39:07 CDT(-0500)] <EricDalquist> maybe it is in Authentication
[11:44:37 CDT(-0500)] <jwennmacher> Maybe PortalPreAuthenticatedProcessingFilter.
[11:44:58 CDT(-0500)] <jwennmacher> Used in spring security
[11:45:14 CDT(-0500)] <jwennmacher> Looks like uPortal partially has spring security in it.
[11:45:26 CDT(-0500)] <EricDalquist> yeah
[11:45:34 CDT(-0500)] <EricDalquist> it uses a little bit of spring-sec
[11:45:52 CDT(-0500)] <jwennmacher> some better than none. At least there is a beach head. 
[11:45:59 CDT(-0500)] <EricDalquist> yeah
[11:46:05 CDT(-0500)] <EricDalquist> I think the biggest complixcating factor is CAS
[11:46:17 CDT(-0500)] <EricDalquist> and the various CAS specific things wityh password caching and proxy tickets
[11:46:19 CDT(-0500)] <jwennmacher> Spring security handles CAS very well
[11:46:32 CDT(-0500)] <EricDalquist> since lots of things in uPortal are looking directly at the CasSecuritycontext
[11:46:41 CDT(-0500)] <EricDalquist> most other code won't notice if the auth layer changes
[11:46:41 CDT(-0500)] <jwennmacher> maybe not those items. Not sure about them.
[11:47:24 CDT(-0500)] <jwennmacher> how does uPortal use proxy tickets? I've seen a bit of code about it. Does uPortal request a proxy ticket to use on portlet calls to back-end systems?
[11:47:32 CDT(-0500)] <EricDalquist> yeah
[11:47:39 CDT(-0500)] <EricDalquist> I'm not that familiar with it
[11:47:47 CDT(-0500)] <EricDalquist> but I think there is a special user attribute name
[11:47:50 CDT(-0500)] <EricDalquist> and if the portlet.xml has that
[11:47:58 CDT(-0500)] <EricDalquist> theportal asks for a proxy ticket for the user
[11:48:06 CDT(-0500)] <EricDalquist> and gives it to the portlet in the user-info map
[11:48:57 CDT(-0500)] <jwennmacher> Do you use shib?
[11:49:06 CDT(-0500)] <EricDalquist> yes
[11:49:57 CDT(-0500)] <jwennmacher> I don't know anything about it. I'll see what I come up with, but I'd really appreciate it if you review the changes I'm making to insure they work with shib (and in general of course).
[11:50:07 CDT(-0500)] <EricDalquist> well shib should be easy
[11:51:09 CDT(-0500)] <jwennmacher> Does shib have its own credentials page like CAS so uPortal never sees the credentials?
[11:51:30 CDT(-0500)] <EricDalquist> correct
[11:51:46 CDT(-0500)] <EricDalquist> it is all done at the apache level though
[11:51:56 CDT(-0500)] <jwennmacher> So how does uPortal handle displaying content for the originally requested url? Does it pass it along to shib?
[11:51:59 CDT(-0500)] <EricDalquist> we just see remote_user and other headers
[11:52:06 CDT(-0500)] <EricDalquist> shib handles that
[11:52:20 CDT(-0500)] <EricDalquist> it captures the URL that results in the redirect
[11:52:24 CDT(-0500)] <EricDalquist> and sends the user back there
[11:52:38 CDT(-0500)] <EricDalquist> I can verify that with our shib admin later today
[11:53:23 CDT(-0500)] <jwennmacher> OK that makes sense. So uPortal never gets the initial request; it is intercepted as a protected url, the user auths, and then the request (from the now authenticated user) will hit uPortal for the first time.
[11:54:07 CDT(-0500)] <EricDalquist> right
[11:54:31 CDT(-0500)] <EricDalquist> it would be like using cas with uportal where cas is all done at the apache level
[11:55:05 CDT(-0500)] <jwennmacher> With shib how does uPortal know the user is authenticated? Presense of a REMOTE_USER header?
[11:55:32 CDT(-0500)] <EricDalquist> yup
[11:55:52 CDT(-0500)] <jwennmacher> What prevents someone from making a request with a REMOTE_USER header and bypassing auth?
[11:55:56 CDT(-0500)] <EricDalquist> apache
[11:56:23 CDT(-0500)] <EricDalquist> that attribute and the attributes shib uses to send user attributes are "protected"
[11:56:34 CDT(-0500)] <EricDalquist> and values sent by the browser are ignored
[11:56:54 CDT(-0500)] <jwennmacher> apache removes those attributes from the browser request and inserts its own?
[11:57:09 CDT(-0500)] <EricDalquist> yup
[11:57:34 CDT(-0500)] <jwennmacher> that makes sense
[11:58:26 CDT(-0500)] <jwennmacher> You've given me a great start on understanding this, and understanding the shib aspects. Thanks.
[11:59:30 CDT(-0500)] <jwennmacher> cwaremire: good to see you. I forgot to ask you to send me your personal contact info. Could you email it to me?
[11:59:43 CDT(-0500)] <jwennmacher> cwaymire I mean. Sorry.
[12:31:48 CDT(-0500)] <cwaymire> jwennmacher: my personal email is chris@waymire.net
[14:07:59 CDT(-0500)] <markmace> is it possible to export a pre defined calendar via the import export portlet? if so, what information do I need? Is a predefined Calendar considered an "Entity type"?
[14:10:30 CDT(-0500)] <jwennmacher> First, see https://issues.jasig.org/browse/CAP-137. Calendar data export is not currently working
[14:10:59 CDT(-0500)] <markmace> ok, thanks. that would explain the jasig error page I see.
[14:11:55 CDT(-0500)] <jwennmacher> Related to your 2nd question, the calendar has its own database tables so it is not part of the entity types you see in the uPortal data import/export.
[14:13:08 CDT(-0500)] <jwennmacher> There is the maven data-export goal that (would) export the calendar database tables. This functionality is not able to be invoked via the uPortal admin UI though. It is only invoked via maven
[14:17:01 CDT(-0500)] <markmace> okay, I can work with that. I'm basically trying to update our predefined calendar xml's as they seem to break the ant initdb target. It's not something that I plan on having to use in production, but it's nice to be able to "refresh" the development environment.
[14:20:38 CDT(-0500)] <jwennmacher> The calendar is now bundled with uPortal. If you run into problems you can look at how the latest version imports data. That might help.
[14:21:16 CDT(-0500)] <markmace> I think I've found the changes to the xml files. Using US_Holidays.pcd.xml as a guide.
[14:31:14 CDT(-0500)] <markmace> thanks, btw - I appreciate the help.
[14:31:57 CDT(-0500)] <jwennmacher> sure
[14:58:44 CDT(-0500)] <EricDalquist> jwennmacher: you can blame cwaymire for all of your deep link woes
[14:59:05 CDT(-0500)] <jwennmacher> Actually I find this challenging and fun
[15:02:23 CDT(-0500)] <jwennmacher> cwaymire: What is RemoteCookieCheckFilter for and what does it do?
[15:02:29 CDT(-0500)] <EricDalquist> so
[15:02:29 CDT(-0500)] <EricDalquist> cookie check
[15:02:29 CDT(-0500)] <EricDalquist> I just did a local test
[15:02:29 CDT(-0500)] <EricDalquist> and the refUrl gets to the login servlet
[15:02:29 CDT(-0500)] <EricDalquist> but the cookie check filter redirects the /Login call to /api/cookieCheck
[15:02:29 CDT(-0500)] <EricDalquist> which borks things
[15:02:30 CDT(-0500)] <EricDalquist> that cookieCheck seems to be a never ending source of problems
[15:02:47 CDT(-0500)] <EricDalquist> it is uspposed to verify that the browser supports cookies
[15:02:52 CDT(-0500)] <EricDalquist> and show an error if it doesn't
[15:03:40 CDT(-0500)] <EricDalquist> but it keeps cropping up as the source of problems
[15:03:46 CDT(-0500)] <EricDalquist> and I'm not sure what to do about it
[15:04:04 CDT(-0500)] <EricDalquist> personally I'm not sure it is really needed
[15:04:12 CDT(-0500)] <EricDalquist> but I don't know what the use case behind it was
[15:04:39 CDT(-0500)] <jwennmacher> I don't see the same behavior you mentioned; I don't see a redirect to /api/CookieCheck
[15:05:33 CDT(-0500)] <EricDalquist> huh
[15:05:48 CDT(-0500)] <EricDalquist> so the order I see is:
[15:05:51 CDT(-0500)] <EricDalquist> go to https://my.wisc.edu/portal/p/financial-information-resources
[15:05:59 CDT(-0500)] <EricDalquist> redirect to: https://login.wisc.edu/idp/profile/SAML2/Redirect/SSO
[15:06:57 CDT(-0500)] <EricDalquist> after auth I get sent back to: https://my.wisc.edu/Shibboleth.sso/SAML2/POST
[15:07:16 CDT(-0500)] <EricDalquist> which sends me to: https://my.wisc.edu/portal/p/financial-information-resources (authd now)
[15:07:35 CDT(-0500)] <EricDalquist> which sends me to: https://my.wisc.edu/portal/Login?refUrl=%2Fportal%2Fp%2Ffinancial-information-resources
[15:07:46 CDT(-0500)] <EricDalquist> which sends me to https://my.wisc.edu/portal/api/cookiecheck
[15:08:03 CDT(-0500)] <EricDalquist> I'm guessing I see that because this is my first visit to the portal
[15:08:18 CDT(-0500)] <EricDalquist> since shib prevents me from ever seeing the guest view
[15:08:41 CDT(-0500)] <EricDalquist> and in our case the cookie check is not capturing all of the request parameters
[15:08:42 CDT(-0500)] <jwennmacher> Probably. The cookie check looks for a JSESSIONID assigned. If not then it thinks you don't have cookies enabled
[15:08:45 CDT(-0500)] <EricDalquist> which makes it barf
[15:08:53 CDT(-0500)] <EricDalquist> yeah
[15:09:52 CDT(-0500)] <jwennmacher> So with what you taught me about Shib this morning I think that makes sense
[15:11:09 CDT(-0500)] <jwennmacher> I assume same behavior if you just access https://my.wisc.edu.
[15:13:29 CDT(-0500)] <EricDalquist> right
[15:13:44 CDT(-0500)] <EricDalquist> the problem is cookieCheck just sends me back to https://my.wisc.edu/portal/Login
[15:13:50 CDT(-0500)] <EricDalquist> instead of https://my.wisc.edu/portal/Login?refUrl=%2Fportal%2Fp%2Ffinancial-information-resources
[15:15:20 CDT(-0500)] <EricDalquist> https://issues.jasig.org/browse/UP-3692
[15:16:17 CDT(-0500)] <jwennmacher> not sure I follow the last part. You mean after https://my.wisc.edu/portal/api/cookiecheck you go back to https://my.wisc.edu/portal/Login?
[15:16:30 CDT(-0500)] <EricDalquist> yup
[15:16:34 CDT(-0500)] <EricDalquist> but without the refUrl
[15:16:40 CDT(-0500)] <EricDalquist> so then I just end up at my default tab
[15:16:53 CDT(-0500)] <jwennmacher> Did you write up a Jira on the cookie check issues?
[15:17:18 CDT(-0500)] <EricDalquist> yup
[15:17:22 CDT(-0500)] <EricDalquist> I just create 3692
[15:17:25 CDT(-0500)] <EricDalquist> created*
[15:17:59 CDT(-0500)] <EricDalquist> ((HttpServletRequest) request).getSession(true).setAttribute(REFERER_ATTRIBUTE,((HttpServletRequest) request).getRequestURI());
[15:18:00 CDT(-0500)] <EricDalquist> yup
[15:18:31 CDT(-0500)] <EricDalquist> it is just using the URI
[15:18:44 CDT(-0500)] <EricDalquist> which doesn't include params
[15:26:01 CDT(-0500)] <jwennmacher> Do you know: If a load balancer is configured to use JSESSIONID for sticky sessions, is the request that creates the session guaranteed to be sent to the same server as the next request where the JSESSIONID is actually sent from the browser? It seems like it would have to be or you could end up in a loop, but then the load balancer would need to look at http responses and not just requests. (this assumes you load balance b
[15:28:04 CDT(-0500)] <EricDalquist> yes
[15:28:08 CDT(-0500)] <EricDalquist> that is how it should work
[15:28:09 CDT(-0500)] <EricDalquist> note if you do that
[15:28:21 CDT(-0500)] <EricDalquist> you need to tell your container you are doing so
[15:28:52 CDT(-0500)] <jwennmacher> you mean the concept is how it should work, or the latter part about session reusing the session ID?
[15:29:03 CDT(-0500)] <EricDalquist> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
[15:29:06 CDT(-0500)] <EricDalquist> see jvmroute
[15:29:14 CDT(-0500)] <EricDalquist> that concept is how it should work
[15:29:18 CDT(-0500)] <EricDalquist> though to be safe
[15:29:25 CDT(-0500)] <EricDalquist> you need to add a jvmroute param
[15:29:36 CDT(-0500)] <EricDalquist> so that you are ensured sessionids are unique across servers
[15:30:04 CDT(-0500)] <EricDalquist> we load balance
[15:30:08 CDT(-0500)] <EricDalquist> but we just do it by IP
[15:42:56 CDT(-0500)] <jwennmacher> So jvmroute is different per server to insure unique ids?
[15:43:01 CDT(-0500)] <EricDalquist> yeah
[15:43:09 CDT(-0500)] <EricDalquist> it just appends that value to the jsessionid I believe
[15:48:37 CDT(-0500)] <EricDalquist> so jwennmacher I think I have a fix
[15:48:39 CDT(-0500)] <jwennmacher> OK. I glanced through the info. Thanks for pointing it out to me. The concept sounds fine. I think it answers my question for at least some scenarios. If using tomcat's clustering approach (software-based clustering), the use of the jvmroute will ensure that if request #1 creates the http session, request #2 will go back to the same server because of this route indication (if I'm following it right).
[15:48:42 CDT(-0500)] <EricDalquist> pushing it out locally now
[15:48:53 CDT(-0500)] <EricDalquist> and I'll push it into jasig's repo tomorrow morning
[15:49:00 CDT(-0500)] <jwennmacher> sounds great.