Skip to "Summary" if you don't need the gory details.
In the recent session patches we modfied the server URL's, to recap with
sessions they are now:
/ipa/ui
unprotected static ui components
/ipa/json
kerberos protected RPC using json
/ipa/xml
kerberos protected RPC using xmlrpc
/ipa/login
kerberos protected URL used to obtain ticket for session
/ipa/session/json
session protected RPC using json
/ipa/session/xml
session protected RPC using xmlrpc (not present yet)
I've been implementing forms based login (i.e. password), which is
another session based method where we obtain a TGT for the user given a
user name and password. We then create a session and store the kerberos
credentials in the new session. From that point forward the use can use
/ipa/session/json just as if had already had a TGT which we obtained via
mod_auth_kerb (because the UI sent a request to /ipa/login on his behalf).
Since obtaining a TGT for the user requires two parameters
(user,password) I initially thought I would create a plugin command. The
RPC command would obtain the TGT, set the session up and return any
errors via the standard RPC error response mechanism. The command would
have to be bound to an unprotected URL because it's used to obtain
credentials.
But after careful consideration I've come to the conclusion a using a
plugin command for this is not a good idea, here's why:
* In the current implementation command dispatch occurs after
authentication validation and is shared by every URL handler.
* An unprotected URL handler would dispatch incoming RPC commands. In
this instance we only want to dispatch EXACTLY 1 command, the
session_password_login() command, nothing else should be dispatched
because every other command demands prior authentication.
We do not have any mechanism to filter which RPC's can be dispatched
according to which URL they arrived on. Implementing this would be akin
to adding authorization logic to RPC dispatch. I don't think that's a
good idea because it would add complex new logic, it would take time to
implement, it might provide unintended access if there is a flaw, and
finally it's redundant to existing ACL's mechanisms which occur after
the command is dispatched.
The original design assumed the server would expose a RPC URL and a UI
URL and that anything arriving on the RPC URL would be authenticated
before it reached our handler and from that point every command could be
dispatched.
With the introduction of sessions we've now deviated from the original
design and it's assumptions.
Summary:
--------
All of the above is background for what I think needs to be done to
support forms based auth.
* Introduce a new URL, /ipa/session/login_password. This is an
unprotected URL. It receives the user and password from URL query
parameters. The URL has exactly one purpose, obtain a TGT, create a
session, store the credentials in the session. There is no RPC on this
URL. Error return is standard HTTP response.
* Move the existing /ipa/login URL to /ipa/session/login_kerberos. The
URL change is to be consistent with the above new URL. The URL change
reflects the fact it is only used to initialize a session when the user
already has a valid kerberos ticket. As before it obtains the
credentials established by mod_auth_kerb and stores them in a session.
We need to recognize that RPC plugin commands are only valid for
authenticated operations. We now have URL's responsible for
non-authenticated operations which is a fundamental change (e.g.
manipulating sessions).
Note that session logout is implmented as a RPC command, manipulating
session authentication via a RPC command would seem to violate the above
principle, but it doesn't because it's only meaningful if you're already
authenticated. It does demand that you're previously authenticated to do
an RPC dispatch. I suppose we could move the session_logout to be
outside of RPC dispatch, not sure it's worth it though, open to thoughts
on this one.
We haven't shipped anything with the new URL layout so tweaking the
URL's a bit should be an issue, plus the URL's under consideration are
NEVER invoked directly by the user, instead the UI does so on behalf of
the user via javascript code.
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
