add challenging authentication needed for cli

Adds the ability to issue authorization challenges back to callers of /authorize.  This is done based on the value of client.RespondWithChallenges which indicates that a particular client wants to be challenged for responses instead of being redirected.

This also adds a few new cli commands (request-token, validate-token, whoami) to exercise the new capabilities.  Right now, the command line client only recognizes basic auth challenges, but the code point for future extension to other challenges is present.

@liggitt review
I guess I bring that up because from Openshift why wouldn't I just use the /user/- call to get myself?  Why would I need this whoami?  And in general we'd want to tie this into our cli login flow commands, rather than a bunch of piecemeal commands.

At this point we've discussed "osc login" and "osc project" as our login entry points.  When would I need to use these commands, and what scenarios would those commands not support ?


> On Nov 26, 2014, at 7:22 AM, David Eads <notifications@github.com> wrote:
> 
> In pkg/auth/server/tokenrequest/endpoints.go:
> 
> >  	"github.com/openshift/origin/pkg/auth/server/login"
> >  )
> >  
> >  const (
> >  	RequestTokenEndpoint = "/token/request"
> >  	DisplayTokenEndpoint = "/token/display"
> > +	WhoAmIEndpoint       = "/whoami"
> >  )
> whoami currently supports all the auth request mechanisms accepted by /authorize, but it would be simple to lock it down to bearer token only (actually, I should probably do that). I think that a method like this has general utility, so that from the command line you can easily see who will be acting as when you run additional commands. Maybe even return information like grants for the token as well.
> 
> I'll lock it down to only the bearer token auth request handler in the next set of updates.
> 
> —
> Reply to this email directly or view it on GitHub.
>