NO-AUTH and NO-SSL

If these are internal interfaces where end users will not have exposure, you can certainly make adjustments as you see fit. However, anything that might be exposed to a general user would encounter interoperability issues based on the requirements in the specification today.

Similar comments as Joseph - is this "lite" functionality just for a particular user / use case or truly for whole device? I can see a lightweight device that "doesn't need" all that support. But there's also a potential class of user that just needs read-only access to some amount of data (thinking an IoT sensor), while the device/service still has the robust security for other users with read-write access for configuration purposes...


Jeff

Thanks Joseph, Jeff,

Yes I think what I was looking is lite redfish where we don't need to do the authentication and secure session between the trusted entity.

Consider a platform which has a platform BMC which is connected to the out of band management port, and one or more satellite BMCs which are connected to the platform BMC via an interface that can run the TCP/IP stack (for eg USB). So, these BMCs could talk Redfish to each other in theory.

In this use case we don't need the authentication and SSL from platform BMC to the satellite BMC

However when the external user talks to the platform BMC entity that channel is secure and authenticated.

SystemUser----Secure/authenticated---->platform BMC----NoSSL/NO-AUTH----->satellite BMC

I had the following asks from the DMTF If my server don't implement the following endpoints

in case of No-Auth:

Account service
ManagerAccount
ManagerAccountCollection
Role
Session Service

in case of No-SSL:
Certificate Service
Certificate location
Certificate collection
Certificate

Will it be considered as a violation of spec? I was just confirming it.

The second ask is, can we think on runtime control of this, where system can go from auth/ssl to no-auth/no-ssl and vice versa,

@mike thanks for your response.

>For your other question about runtime control, no that is not in place today and would require further discussion.

It makes sense if we are considering the use case of internal channel with redfish. I understand that current redfish spec supports HTTP but in that case the redfish server doesn't need to implement the following

Certificate Service
Certificate location
Certificate collection
Certificate

If there are no other network services where the certificates are required.

Now coming back to authentication part: Right now the spec says

> "Services shall authenticate all write requests to Redfish resources"

In our use case which I explained above, we don't need our internal client (which is part of the system) to be authenticated, I know till now standard focuses on the public facing interface where we require some form of authentication before client does any write request.

Can we accommodate this use case also in the standard if there are other company's who have some form of similar use cases.

There's two levels here, one that probably takes some minor tweaks to the specification to ensure it's well understood, and another level that require a lot more discussion...

If you're just trying to avoid the "overhead" (in every sense of the word) of the secure protocol, and effectively just want to "turn off that support" for your configuration, I can see that as a valid use case and it's probably not unique to you. And again, if these internal interface(s) aren't available to the public / end user - there's no harm in violating the specification regardless. But I assume that the satellite BMC code is supposed to be "Redfish standard conforming" (because it wasn't written solely for this configuration) and may be used in other configurations where that security is desired/required, then I understand why you want that code to pass conformance tests.

So that said, as long as the secure protocols and authentication methods, as called out in the specification, are actually supported by the implemented, but are "turned off" for your configuration (hopefully using Redfish methods), then I could see the group working through whatever changes / clarifications are necessary to allow for that...

But if the goal is to produce a satellite BMC firmware that does NOT contain the support for authentication or HTTPS at all - that is a very different animal. We would probably be talking about a new "class" of device and/or specification - because I believe the standards group would have difficulty enabling a completely insecure implementation to claim to be "conforming to the Redfish specification".

The simple analogy is: All the doors in the building have to have locks. But it's acceptable for the building owner to leave all those doors unlocked (and even put up signs that say "This door to remain Unlocked") so no one has to deal with the keys and the hassle.

Jeff