On 6/24/16 9:53 AM, John Dennis wrote:
Let me try to clarify a few things.
PAM is designed as a "conversation", there are a few analogues you could
compare it to:
* a series of requests/responses
* challenge/response authentication (e.g. CRAM)
PAM has something equivalent to a session where state is stored during
the "conversation". When you use PAM you establish a context (session)
and iterate. In each iteration the PAM library will ask you for
something and you reply. The iteration stops when the library signals
completion.
Will the PAM conversation object be able to be serialized in-between web
requests? Is it something that can be rebuilt with HTTP session information?
For simple password auth the iteration is very short. But depending
on
how the PAM service is configured you could be prompted for other
things. I suspect with Web forms they way you handle this is via
redirects until such time as the PAM conversation completes.
What do you mean by "prompted"? Are we going to have to screen-scrape
this information, or is it a well defined structure?
So my suggestion would be to design this where there is a simple web
form prompting for username/password but allow for the fact you may have
to redirect to another page.
As I mentioned early, we already have these generic redirection
capabilities. Login is a "workflow" and you can define nodes in this
workflow. The current node in the flow can fail, pass, ignore, or
challenge an incoming request.
Does that help?
We're getting there! :) My current thoughts are that PAM integration
should be implemented as a Keycloak Authenticator and user profile
lookup, via SSSD, should be done via a User Federation Provider (the new
interface).
Bill