Proposal for the connected redfish client info

[Ratan Gupta]

Hi James, Ivan, Richard,

Please go through the mail below, I responded the queries.

Let me know if we have concern around this.

Ratan

On 3/20/20 12:50 PM, Ratan Gupta wrote:
>
> Hi James,Ivan,Richard
>
> The Intention of the below requirement is to help the clients to find 
> the other connected clients in realtime.
>
> Richard, As you mentioned in other thread
>
> *"Or is this being to log accesses for security audits? I think that 
> would help me figure out what direction we should move towards."*
>
>  It may get used for security audits but didn't think before you 
> pointed out.
>
>
> On 3/17/20 9:28 PM, James Feist wrote:
>> On 3/17/2020 6:01 AM, Ratan Gupta wrote:
>>> Hi Team,
>>>
>>> Looking for your inputs
>>>
>>> James, How about option1 for the below use case
>>
>> Before creating OEM we are to propose it to the Redfish community. 
>> Have you asked them for their thoughts?
> My plan was to ask from the openBMC community first about the 
> requirement, If the community interested in this we can propose it to 
> the Redfish-Forum.
>>
>>>
>>> Ratan
>>>
>>> On 3/11/20 3:48 PM, Ratan Gupta wrote:
>>>>
>>>> Hi Team,
>>>>
>>>> In IBM we have a following requirement
>>>>
>>>>   * Show the connected redfish client info.
>>>>       o   ClientIP >>       o   Client Unique Identifier(unique 
>>>> serial number of the 
>> client etc)
>>
>> This confuses me, how are you getting the serial number for a 
>> connected client? If so, have you looked into data protection laws 
>> and storing Personally Identifiable Information?
>
> Client have to give this info, it could be anything like hostname of 
> the client, serial number of the machine etc, it is up to the client 
> what they want to provide as part of client identifier.
>
> Why it is needed?
>
> Consider the below use case
>
> => Client(x.x.x.x) creates the session with BMC
>
> => BMC stores this IP(x.x.x.x)
>
> => Now say Client IP(x.x.x.x) got change to y.y.y.y but the session is 
> still valid.
>
> => Stored IP(x.x.x.x) will not be much usable here in this scenario
>
> => Here Client Identifier may be usable to identify the connected client.
>
> Let me know your thoughts here.
>
>
>>
>>>>
>>>>
>>>> Presently there is no way through which we can get this info.
>>>>
>>>> I have following two proposal for the above requirement.
>>>>
>>>> 1/ (Extend the session schema)
>>>>
>>>> Add the IPaddress and the client Identifier as a OEM in the session 
>>>> schema,
>>>> Clinet IP would be read only and will be updated once the redfish 
>>>> client creates the session.
>>>> ClientIdentifier(Management console unique serial number etc) will 
>>>> be writable property and can be set by the redfish client
>>>> during creation of the session or after creating the session.
>>>>
>>>>
>>>> 2/ (Create the Manager object at runtime)
>>>> once the redfish client creates the session , bmcweb internally 
>>>> does the following
>>>>
>>>> - Create the manager object whose type is "Management Controller".
>>>>
>>>> - Create the ethernet interface resource manager resource and 
>>>> update the client IP.
>>>>
>>>>    In the second option how to set the Client unique identifier 
>>>> which is to be given by the Redfish client
>>
>> I've had talks before about creating a new systems schema for the BMC 
>> specifically, so that you could expose things like bmc memory, etc. 
>> Systems also has the Ethernet schema. However this depends on what 
>> you're trying to present.
>>
> Here I was proposing to create a manager object for the external 
> clients, once they creates the session with the BMC. I am not sure 
> what else we can set for the connected client in the manager object so 
> I was inclined towards extending the session schema instead of 
> creating the manager object for external clients.
>>>>
>>>>  Please let me know your thoughts on the above.
>>>>
>>>> Ratan
>>>>
> Ratan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200326/d7e3b959/attachment-0001.htm>