[Freeipa-devel] plugin limitations and more URL modifications

[John Dennis]

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 <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/