[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