On Tue, 2009-01-20 at 14:06 -0800, Dirk Brandewie wrote:
> Hi All,
>
> The credential agent interface doc in the repository is a place holder I
> have been thinking about what the credential agent interface should be
> and would like to know what other think about the semantics and usage
> model of the interface should be.
>
> The reason for the agent API is to give the WiMax daemon a way to
> collect login credentials from the user (username, password).
>
> The simple case is the agent object would throw up a dialog for the user
> to enter the required information. This is kind of clunky and would
> become really annoying in the case where you lose connection and are
> trying to automatically trying to connect.
>
> It would be nice to support auto-reconnect with out user intervention.
> The agent could cache the credentials but now we have the credentials
> laying around one method call away from anyone that wants them good guy
> or bad.
>
> One solution I thought of that would help is to change the
> RegisterCredentialAgent() method in the adapter object to take an
> additional context argument to be passed back to the credential agent
> that is set by the connection/network manager.
>
> So the flow would look something like this:
> org.wimax1.Agent.SetCredentials({ "Username": "dcbw",
> "Password": "foobar",
> <context_value>)
> org.wimax1.Adapter.RegisterCredentialAgent("/something/I/make/up", 0xDEADBABE)
> org.wimax1.Network.Connect()
>
> The callback from the WiMax daemon would be
> org.wimax1.Agent.GetCredentials( in uint32 context,
> out string username,
> out string password);
>
> If the context value does not match the value passed to org.wimax1.Agent.SetCredentials()
> the method returns an error and possibly nukes the credentials to prevent a brute force attack
> looking for correct context value.
Hmm, I still don't quite understand how you're thinking about
credentials. In my mind, there are 3 parts to the whole stack (ignoring
the driver of course):
* Connection Manager (CM): a privileged, non-GUI process that controls
(at a high level) which network devices are connected, and begins/tears
down those network connections based on system events or user requests
* WiMAX network service (WS): a privileged, non-GUI process that
controls WiMAX network devices
* Agent (A): a non-privileged, GUI process running in user-context (ie,
not root or Administrator or whatever) that retrieves the user's
credentials, possibly by showing a dialog and requesting them, or by
reading user's saved preferences/credentials
Often, the Agent will be closely tied to the Connection Manager to
ensure consistent user experience and seamless operation.
In the case of NetworkManager, the Agent (nm-applet) is used for *all*
credentials, for Wifi, 802.1x, GSM/CDMA, PPPoE, VPN, and would be used
for WiMAX too. It would be pointless and more code to have the Agent
talk directly to the WiMAX network service, since the Agent would then
have two completely different code paths: one for WiMAX, and one for
WiFi/802.1x/GSM/CDMA/PPPoE/VPN/etc Thus, in the NetworkManager model,
the Connection Manager would the part responsible for sending the
correct credentials to the WiMAX service, which it obtains on-demand
from the Agent. The WiMAX service would somehow need to inform the
Connection Manager (or any other interested process) that Credentials
were required, likely through a D-Bus signal.
I'd expect that the WiMAX service would be able to request credentials
when it needs them; ie if they are stored in NVRAM or something and not
required, then the credentials would not be requested.
Also, I'd expect that the Credentials API be part of the *Adapter*
interface, or even the base service D-Bus interface, because I would
expect the same Agent to be used irregardless of what adapter or network
was being connected to. Thus, moving anything to do with the Agent into
the org.wimax1.Adapter or org.wimax1 interface would be more useful.
My suggestion is to restrict the Credentials D-Bus interface to be
accessible only to the 'root' user (via policy in
the /etc/dbus-1/system.d/org.wimax1.conf permissions file), and let the
connection manager handle credential security, since Connection Managers
and Agents are often tightly connected. No further security is required
since only root could call ProvideCredentials() in the API above. The
connection manager is responsible for ensuring that only intended
processes can fill the role of the Agent. Further fine-grained access
control can certainly be provided by PolicyKit.
Or, could you explain how the flow of your proposal would go, saying
which process/component would make each request or call? That's
probably the part I'm finding confusing, I'm not sure in your examples
what process is performing each part of the process.
Dan
----------------------------------------------------------------------
A different mechanism:
- The connection manager sends a "context_value" and a "secret" along
with the Connect() method. This context_value is stored with the
Network object over the life-time of the connection.
- When the WiMAX service requires credentials, it emits the signal:
org.wimax1.Adapter.CredentialsRequested(object network, string context_value)
- The connection manager (or the Agent, if the Agent knows the secret)
call the following method of the Adapter:
org.wimax1.Adapter.ProvideCredentials(string context_value,
string secret,
bool allow_cache,
array{string:variant} credentials)
Only if the secret matches what was sent with Connect() are the
credentials accepted. One issue with this API is that if the connection
manager or Agent crash, they do not retain the secret, and thus cannot
respond to subsequent CredentialsRequested signals. My take: this
method has too much unnecessary "magic".
--------------------------------------------------
A third mechanism:
- Connection Manager connects with:
org.wimax1.Network.Connect(string agent_service, object agent_object, string context_value)
- If the WiMAX service requires credentials, the *WiMAX service* calls
the:
array{string:variant} GetCredentials(object adapter, object network, string context_value)
method of the D-Bus service that was referenced in the Connect() method
above. This means that the WiMAX service would need to have appropriate
permissions to talk to the Agent, which itself would provide a D-Bus
service on the system bus. The connection manager would then be
responsible for knowing what Agent to use, which it already has to know,
since often the Connection Manager and the Agent are from the same
software provider or project. My take: this method also has too much
unnecessary "magic".
