I think utilizing the "saveRestoreRequest" method to then redirect the user to the originally requested URL after authentication is ideal and leads to a much more intuitive experience for the user.
As for the AssertionConsumerServiceURL...again - I don't want to have to manually specify the URL. Having to manually specify a protected resource in the config leads to a number of issues.
1) If I change what resources are protected in my web.xml, I have to remember to possibly update picketlink.xml
2) A good majority of our web apps are accessible via a reverse proxy and manually specifying the URL means that SAML authentication will not work in all cases. We have an internal server accessible via our intranet, but we don't want to make it available externally. So we set up a reverse proxy in these cases to make certain apps on that server available externally. If I have a web app (http://someserver.com:8443/webapp) that is accessible via a reverse proxy (http://reverseproxy.com:443/webapp), manually specifying the ACS URL in the config means that after authentication, every user will ALWAYS be sent to the ACS URL specified in the config - even if that URL isn't accessible except through the reverse proxy. For example, if I specify the ACS URL for the web app as "http://someserver.com:8443/webapp/proctedResource.jsp", when a user connecting externally via "http://reverseproxy.com:443/webapp" finishes the authentication on the IdP, they are redirected to "http://someserver.com:8443/webapp/proctedResource.jsp" which results in a timeout because that server isn't available externally - the request should have gone through the reverse proxy. Another issue arises from the opposite case...if I specify the ACS URL as "http://reverseproxy.com:8443/webapp/proctedResource.jsp" and I access the resource internally via "http://someserver.com:8443/webapp/", after authentication when the IdP redirects me back to the ACS URL, I'm sent to a different server than the one that issued the session cookies.
So ideally, it would be nice if PicketLink (as an SP) would default the ASSERTION_CONSUMER_URL to the originally requested resource (with the proper host name and port from the original request retrieved via httpServletRequest.getServerName()) in SAML2AuthenticationHandler$SPAuthenicationHandler.generateSAMLRequest() if its not defined instead of defaulting to the ServiceURL (which is really the SAML entityID).