Plan to unify REST authentication?

Plan to unify REST authentication?

[Joseph Reynolds]

What is the plan to unify the Redfish and Phosphor REST authentication 
mechanisms?

Here is my understanding:

OpenBMC has two different HTTP servers which serve two different sets of 
REST APIs:
1. BMCWeb serves Redfish REST APIs (when BMCWEB_ENABLE_REDFISH is used 
[1]) and serves Phosphor REST APIs [2] (when BMCWEB_ENABLE_DBUS_REST is 
used [1]) via a C++ implementation in bmcweb.
2. The meta-ibm nginx configuration [3] serves Redfish (via BMCWeb 
listening at port 8082) and serves Phosphor REST APIs (via the 
Python-based phosphor-rest-server [4] listening at port 8081).

The project's direction is to move exclusively to BMCWeb (and 
discontinue using nginx) and Redfish (and discontinue using 
phosphor-rest).  Note that the BMCWeb C++ Phosphor REST implementation 
does not yet offer the same functions as provided by the Python-based 
phosphor-rest-server APIs, and work is in-progress to achieve required 
functions in bmcweb [5] and phosphor-objmgr [6].  Development work might 
happen like this (the staging plan):

1. Continue working on BMCWeb Phosphor REST functions until 
openbmc-test-automation [7] tests pass.
2. Change the meta-ibm layer to use BMCWeb with BMCWEB_ENABLE_DBUS_REST, 
and discontinue using nginx.
3. Continue adding Redfish functions to BMCWeb until we no longer need 
Phosphor REST functions.
4. Change the meta-ibm layer so BMCWeb no longer uses 
BMCWEB_ENABLE_DBUS_REST by default.

When this is all done, we will have achieved the goal of using BMCWeb 
and Redfish exclusively.

Note that the Redfish REST APIs and the Phosphor REST APIs use different 
authentication mechanisms.  Both take your username and password but 
return different credentials (which are needed for subsequent privileged 
access).  For Redfish, posting to /redfish/v1/SessionService/Sessions 
returns a session id and an X-Auth-Token [8].  For Phosphor REST, 
posting to /login returns a Session Cookie [2].

Applications such as the phosphor-webui web application and xcat 
currently use the Phosphor REST APIs, but will begin to use the Redfish 
REST APIs, perhaps using both sets of APIs in the same application.   
Will they need to login to both sets of REST APIs?

In this context, what is the plan to unify the authentication scheme?  I 
heard something about changing BMCWeb's version of the Phosphor REST 
APIs so that when you post to /login, you get the same credentials as 
from /redfish/v1/SessionService/Sessions.  Will I be able to login using 
/login and use Redfish APIs, and vice-versa?

- Joseph
__________

[BMCWeb]: https://github.com/openbmc/bmcweb/blob/master/README.md
[nginx]: https://www.nginx.com/
[phosphor-webui]: 
https://github.com/openbmc/phosphor-webui/blob/master/README.md
[xcat]: https://xcat.org/
[1]: https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt
[2]: https://github.com/openbmc/docs/blob/master/rest-api.md
[3]: 
https://github.com/openbmc/meta-ibm/blob/master/recipes-httpd/nginx/files/nginx.conf
[4]: https://github.com/openbmc/phosphor-rest-server
[5]: https://gerrit.openbmc-project.xyz/#/q/project:openbmc/bmcweb
[6]: 
https://gerrit.openbmc-project.xyz/#/q/project:openbmc/phosphor-objmgr
[7]: 
https://github.com/openbmc/openbmc-test-automation/blob/master/README.md
[8]: https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md

Re: Plan to unify REST authentication?

[Ed Tanous]

On 1/9/19 2:53 PM, Joseph Reynolds wrote:
> The project's direction is to move exclusively to BMCWeb (and 
> discontinue using nginx) and Redfish (and discontinue using 
> phosphor-rest).

This is my long term goal as well, and how Intel systems currently
operate (despite the bugs it currently causes)

>   Note that the BMCWeb C++ Phosphor REST implementation 
> does not yet offer the same functions as provided by the Python-based 
> phosphor-rest-server APIs, and work is in-progress to achieve required 
> functions in bmcweb [5] and phosphor-objmgr [6].
The c++ mapper was merged already, and seems to be stable.
>   Development work might 
> happen like this (the staging plan):
>
> 1. Continue working on BMCWeb Phosphor REST functions until 
> openbmc-test-automation [7] tests pass.
> 2. Change the meta-ibm layer to use BMCWeb with BMCWEB_ENABLE_DBUS_REST, 
> and discontinue using nginx.

A possible path for this step is staged here:

https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/14171

> 3. Continue adding Redfish functions to BMCWeb until we no longer need 
> Phosphor REST functions.

This point warrants much greater discussion, but I think we need to get
through 1 and 2 before we start diving into the details on how to
execute moving phosphor REST to Redfish.

> 4. Change the meta-ibm layer so BMCWeb no longer uses 
> BMCWEB_ENABLE_DBUS_REST by default.

I'm not following this one.  I suspect you meant to say the opposite?

> When this is all done, we will have achieved the goal of using BMCWeb 
> and Redfish exclusively.
>
> Note that the Redfish REST APIs and the Phosphor REST APIs use different 
> authentication mechanisms.  Both take your username and password but 
> return different credentials (which are needed for subsequent privileged 
> access).  For Redfish, posting to /redfish/v1/SessionService/Sessions 
> returns a session id and an X-Auth-Token [8].  For Phosphor REST, 
> posting to /login returns a Session Cookie [2].

Bmcweb also supports the /login api, which takes the same parameters,
and returns the same data.  The only functional difference is that it
implement CSRF prevention, which requires a second token to be issued
along with the cookie, to avoid XSS and CSRF attacks.  This makes it
incompatible in a minor way.  For testing, it's disableable through the
option BMCWEB_INSECURE_DISABLE_CSRF_PREVENTION.

In the bmcweb model, session information is shared across the whole
application, so websocket, REST, KVM, and KVM sessions all share the
same tokens and login mechanisms, which allows more compatibility with
applications, and allows users to pick the login mechanism that works
best for their application.

> Applications such as the phosphor-webui web application and xcat 
> currently use the Phosphor REST APIs, but will begin to use the Redfish 
> REST APIs, perhaps using both sets of APIs in the same application.   
> Will they need to login to both sets of REST APIs?
In the "bmcweb is the only webserver" model, no, it wouldn't be required to.
>
> In this context, what is the plan to unify the authentication scheme?  I 
> heard something about changing BMCWeb's version of the Phosphor REST 
> APIs so that when you post to /login, you get the same credentials as 
> from /redfish/v1/SessionService/Sessions.  Will I be able to login using 
> /login and use Redfish APIs, and vice-versa?

Already implemented, and has been for some time.

https://github.com/openbmc/bmcweb/blob/4ae611d9de1504b68f521e9837ddb97e0dc89d27/include/token_authorization_middleware.hpp#L274

>
> - Joseph
> __________
>
> [BMCWeb]: https://github.com/openbmc/bmcweb/blob/master/README.md
> [nginx]: https://www.nginx.com/
> [phosphor-webui]: 
> https://github.com/openbmc/phosphor-webui/blob/master/README.md
> [xcat]: https://xcat.org/
> [1]: https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt
> [2]: https://github.com/openbmc/docs/blob/master/rest-api.md
> [3]: 
> https://github.com/openbmc/meta-ibm/blob/master/recipes-httpd/nginx/files/nginx.conf
> [4]: https://github.com/openbmc/phosphor-rest-server
> [5]: https://gerrit.openbmc-project.xyz/#/q/project:openbmc/bmcweb
> [6]: 
> https://gerrit.openbmc-project.xyz/#/q/project:openbmc/phosphor-objmgr
> [7]: 
> https://github.com/openbmc/openbmc-test-automation/blob/master/README.md
> [8]: https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md
>

Re: Plan to unify REST authentication?

[Matt Spinler]

Hi,

I've been working quite a bit to get bmcweb's REST APIs working well
enough to pass all of our existing robot testcases, and I'd say it's at
a point now where I think we can proceed with replacing phosphor-rest
with bmcweb as the REST server in meta-phosphor, and of course also in
meta-ibm.  There are 2 or so commits that still need to merge in either
bmcweb or openbmc-test-automation, but that will happen imminently.

The basic commit to do this is:
https://gerrit.openbmc-project.xyz/#/c/openbmc/openbmc/+/14172/.

There are also a few other commits to remove nginx as well in the
IBM layer.

As Ed mentioned below, bmcweb has CSRF prevention enabled, which
requires one to pass in a token, obtained from the login, to do
PUTs and POSTs.  The web UI and the robot tests handle this. Are
there any concerns with this protection being in master?

Any other concerns, questions, etc about doing this?

Thanks,
Matt


On 2019-01-14 11:17, Ed Tanous wrote:
> On 1/9/19 2:53 PM, Joseph Reynolds wrote:
>> The project's direction is to move exclusively to BMCWeb (and
>> discontinue using nginx) and Redfish (and discontinue using
>> phosphor-rest).
> 
> This is my long term goal as well, and how Intel systems currently
> operate (despite the bugs it currently causes)
> 
>>   Note that the BMCWeb C++ Phosphor REST implementation
>> does not yet offer the same functions as provided by the Python-based
>> phosphor-rest-server APIs, and work is in-progress to achieve required
>> functions in bmcweb [5] and phosphor-objmgr [6].
> The c++ mapper was merged already, and seems to be stable.
>>   Development work might
>> happen like this (the staging plan):
>> 
>> 1. Continue working on BMCWeb Phosphor REST functions until
>> openbmc-test-automation [7] tests pass.
>> 2. Change the meta-ibm layer to use BMCWeb with 
>> BMCWEB_ENABLE_DBUS_REST,
>> and discontinue using nginx.
> 
> A possible path for this step is staged here:
> 
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/14171
> 
>> 3. Continue adding Redfish functions to BMCWeb until we no longer need
>> Phosphor REST functions.
> 
> This point warrants much greater discussion, but I think we need to get
> through 1 and 2 before we start diving into the details on how to
> execute moving phosphor REST to Redfish.
> 
>> 4. Change the meta-ibm layer so BMCWeb no longer uses
>> BMCWEB_ENABLE_DBUS_REST by default.
> 
> I'm not following this one.  I suspect you meant to say the opposite?
> 
>> When this is all done, we will have achieved the goal of using BMCWeb
>> and Redfish exclusively.
>> 
>> Note that the Redfish REST APIs and the Phosphor REST APIs use 
>> different
>> authentication mechanisms.  Both take your username and password but
>> return different credentials (which are needed for subsequent 
>> privileged
>> access).  For Redfish, posting to /redfish/v1/SessionService/Sessions
>> returns a session id and an X-Auth-Token [8].  For Phosphor REST,
>> posting to /login returns a Session Cookie [2].
> 
> Bmcweb also supports the /login api, which takes the same parameters,
> and returns the same data.  The only functional difference is that it
> implement CSRF prevention, which requires a second token to be issued
> along with the cookie, to avoid XSS and CSRF attacks.  This makes it
> incompatible in a minor way.  For testing, it's disableable through 
> the
> option BMCWEB_INSECURE_DISABLE_CSRF_PREVENTION.
> 
> In the bmcweb model, session information is shared across the whole
> application, so websocket, REST, KVM, and KVM sessions all share the
> same tokens and login mechanisms, which allows more compatibility with
> applications, and allows users to pick the login mechanism that works
> best for their application.
> 
>> Applications such as the phosphor-webui web application and xcat
>> currently use the Phosphor REST APIs, but will begin to use the 
>> Redfish
>> REST APIs, perhaps using both sets of APIs in the same application.
>> Will they need to login to both sets of REST APIs?
> In the "bmcweb is the only webserver" model, no, it wouldn't be 
> required to.
>> 
>> In this context, what is the plan to unify the authentication scheme?  
>> I
>> heard something about changing BMCWeb's version of the Phosphor REST
>> APIs so that when you post to /login, you get the same credentials as
>> from /redfish/v1/SessionService/Sessions.  Will I be able to login 
>> using
>> /login and use Redfish APIs, and vice-versa?
> 
> Already implemented, and has been for some time.
> 
> https://github.com/openbmc/bmcweb/blob/4ae611d9de1504b68f521e9837ddb97e0dc89d27/include/token_authorization_middleware.hpp#L274
> 
>> 
>> - Joseph
>> __________
>> 
>> [BMCWeb]: https://github.com/openbmc/bmcweb/blob/master/README.md
>> [nginx]: https://www.nginx.com/
>> [phosphor-webui]:
>> https://github.com/openbmc/phosphor-webui/blob/master/README.md
>> [xcat]: https://xcat.org/
>> [1]: https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt
>> [2]: https://github.com/openbmc/docs/blob/master/rest-api.md
>> [3]:
>> https://github.com/openbmc/meta-ibm/blob/master/recipes-httpd/nginx/files/nginx.conf
>> [4]: https://github.com/openbmc/phosphor-rest-server
>> [5]: https://gerrit.openbmc-project.xyz/#/q/project:openbmc/bmcweb
>> [6]:
>> https://gerrit.openbmc-project.xyz/#/q/project:openbmc/phosphor-objmgr
>> [7]:
>> https://github.com/openbmc/openbmc-test-automation/blob/master/README.md
>> [8]: https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md
>> 

Re: Plan to unify REST authentication?

[Ed Tanous]

On 1/23/19 11:29 AM, Matt Spinler wrote:
> There are 2 or so commits that still need to merge in either
> bmcweb or openbmc-test-automation, but that will happen imminently.
> 
I just merged both of your commits.  They should be included in an
autobump shortly.


In case it wasn't apparent, or needed to be said, merging this change to
master has my support.