On Tue, 2009-02-03 at 12:41 -0800, Dan Williams wrote:
> 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.
I agree the agent should be tied/part of the connection manager. The
point is to specify how the wimax stack can collect the user credentials
which may be required while processing the Connect() call. The agent is
not part of the stack although we would likely implement a toy agent for
testing the interface.
>
> 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 hadn't considered using signals for the exchange between the stack and
the connection manager. I am perfectly willing to lose the agent
interface completely if we can define a set of signals that can do the
job.
>
> 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.
I moved the interface to the network since the credentials are/maybe
needed during the Connect() call. They are not a property of the
adapter.
>
> 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.
>
Great no reason for the context value if we stick with the agent
interface. Can the same level of control be placed on signals?
> 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.
>
The connection manager would instantiate the agent and register it with
the network object. When the network object required the credentials ti
would call out to the agent to retrieve them. How the agent actually
gets the credentials (UI, keyring, etc) would be up the the implementer.
> 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".
>
>
I will take direction from the community on the "right" interface is I
don't have a preference other than it should be reasonable implement.
The common API produced by sprint has a API for the connection manager
to provide username password to the stack. The agent interface is an
attempt to proved that functionality in the DBus API. At the moment I
am unaware of any network provider using username/password to enter the
network. We could postpone the whole agent interface discussion until
there is a need in the wild.
--Dirk
