JSP files in the war

[Rod Widdowson]

I have just checked in a port of the V2 jsp login file into the war file.  I
have also tested all V2 taglibs and started to add some fake UI type  to our
test metadata to expedite testing - both for jsp and for the velocity stuff.

The logout and shibboleth.jsp files are partially ported (which is to say
stubbed out with an error message).  I have distinguished the error.jsp that
is called from within spring to the one that is called from without.

As discussed yesterday, I did have to add a statement to the mvc-beans file

    <mvc:resources mapping="/resources/**" location="/resources/" />

Which appears to be what makes things like logos and css files available
from within the war file.  IANA spring expert (but I'm learning) so if this
is wrong, please let me know.

That change made me realize that I do not know how we intend dealing with
css for our velocity resolved pages.  I would guess that our default
velocity pages will reference the embedded css file and more complex cases
can be left as an exercise for the deployer.

I do not believe that the error handling is correct yet.  I have not
bottomed this out (and will not be able to before Monday at the earliest),
but using velocity, the old, or the new jsp pages I got reasonably
non-deterministic behaviour from a failed login.

- Sometime we would end up issuing a SAML error statement

- Sometime (but not all the time) the SAML warning was also accompanied in
the log with a warning that the 'providerId' wasn't present (I am testing
using the unsolicited endpoints, because the other ones are temporarily not
work with some sort of security warning
(org.opensaml.security.SecurityException: No signature algorithm was
available on the signing parameters or Signature ) which I did not feel
strong enough to debug on a Saturday morning.

- Other times I did get back to the login page but the expected request
attributes (authenticationErrorContext & authenticationWarninfContext) were
not there.  And hence I could not indicate the failed login.    I did add
some "debug via printf" debugging and saw that we were getting the
flowRequestContext and from that located the profileRequestContext and
authenticationContext, but the authenticationContext did not have the child
contexts I expected to see there. 

- I have seen the expected error using the velocity template and I may have
also seen it using the old jsp file.  But I never have with the new one
which makes me suspect that I have broken something there.

I'll welcome hints on where to start looking for that, or is this all
stabilisation work which is planned for next week?

Once I have that fixed I will start looking at building a context for
velocity and thus porting the V2 login page to velocity.  I'll start with a
single locale and work out, but I am not intending checking any of this
stuff in until June since (a) I'll not be about to fix it and (b) I don't
think it would be ready even for an alpha test.

Rod