Thanks for the answers; I certainly didn't expect it to be so quick!

> Do you have the code available somewhere - github or something like that?
> I'd be happy to download it and take a look at what's happening.

Unfortunately, no, it's just POC at this point.

> Out of curiosity, is this configurable with the IDP?  I know when I wrote
> the CAS extension there's an option when you request CAS authentication
> that
> allows you to specify how you get the ticket back - as a post or get
> response.  I'm curious if the IDP you're using has something similar?  I
> think I ran into similar issues when I was trying to make the CAS
> extension
> use a POST instead of GET, but I can't remember.

The SAML protocol does support redirect responses, yes, but the SAML
response that comes back, with all of the assertions, is too large for a
redirect URL (~9,200 bytes, max length for a URL is ~2,048).  Unlike OpenID,
it doesn't look like there's any "here's a token, call this service to look
it up" implementation, which is annoying.

So:

I did find the work that Mike Jumper did for allowing extensions to host
their own REST APIs.  I am using this to host a method that is receiving the
SAML POST form.

This works fine, and I can validate the response.  The problem I have now is
getting that information into guacamole's session.

My first thought was just to call the same code as /api/tokens, but the
authentication code (authenticationService, etc) do not seem to be in
guacamole-common or guacamole-ext.  So the options that I've come up with so
far are:

1) Manually call /api/tokens from my ext web service, take it's token,
redirect to the main page passing the token, which will get passed back to
/api/tokens when the main page calls it.  This seems so pretty klunky, but
involves the least duplication of code.

2) What Mike suggested: Validate SAML response, generate my own token (with
blackjack, and hookers!), store it somewhere, pass it back, and then look it
up when /api/tokens gets called.  This seems less klunky than #1, but
requires essentially duplicating the token management code that's already in
use.

3) Throw abstraction out the window and just add my code to
guacamole-client.  Horribly klunky, torpedoes future upgrades without
additional effort.

4) Mystery fourth option

Is there a #4 that I'm missing?



--
Sent from: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/

Reply via email to