[OGSA-AUTHZ] btg scenario in D12.2

[David Chadwick]

Dear Authz WG

please ignore this thread as you were copied in by mistake (unless you 
want to discuss Break The Glass authz policies)

regards

David


On 20/11/2010 13:27, David Chadwick wrote:
> Hi Stijn
>
> the bulk of your code is a Tomcat servlet, but doesnt this require an
> Apache web page GUI for the user to talk to, and the latter then talks
> to your servlet.
>
> If this is the case, then I dont see why the string in the email message
> cannot be a URL rather than a string to cut and paste
>
> regards
>
> David
>
>
> On 19/11/2010 15:38, Stijn Lievens wrote:
>> Hi David,
>>
>> On 18/11/10 13:39, David Chadwick wrote:
>>> Hi Stijn
>>>
>>> On 17/11/2010 22:03, Stijn Lievens wrote:
>>>> Hi David,
>>>>
>>>> I think the BTG scenario is D12.2 is reasonably feasible apart from the
>>>> following bits:
>>>>
>>>> - at the moment the BTG-PDP does not offer a way to inspect the BTG
>>>> state. This seems to be necessary for step (d) 'Supervisor resets the
>>>> glass'.
>>>
>>> No its not, since the user explanation is already made available to the
>>> supervisor in two ways
>>>
>>> i) in the email
>>> ii) in the audit trail.
>>>
>>> So there is no requirement for the supervisor to inspect the BTG state
>>> inside the PDP since either of the above can be used to tell the
>>> supervisor which state was set. If the email and/or audit trail contain
>>> the exact BTG state variable that was set, then the supervisor knows
>>> which one to reset. But the supervisor will need a GUI for resetting the
>>> state, and as a hack, the variable could be hardcoded into the GUI
>>> rather than it being a variable parameter.
>>>
>>>
>>> At the moment the demo has a very crude facility to reset the
>>>> glass by clearing the whole table.
>>>
>>> well the reset GUI could have this hardcoded in as well for the demo.
>>> Although it would be better if it was configurable.
>>>
>>> Idea. If the audit trail or email convert the BTGi state into a URL,
>>> which the manager can click on, and the web page takes this URL to
>>> formulate a reset request to the BTG PDP, then you can put whatever
>>> magic you want in the URL and the web page script can do whatever it
>>> wants with it in order to create the correct BTG reset request.
>>>
>>> What do you thank about this?
>>>
>>
>> I have now implemented the following. In the email, the policy writer
>> should include a query-string that will contain the necessary parameters
>> to find the correct row in the BTG table.
>>
>> On the GUI (which for now can only reset rows from a single table,
>> although this can be changed quite easily), the administrator then has
>> to paste the query string from the email.
>>
>>
>>
>>
>>>
>>> I don't know how to (quickly) fix
>>>> this issue. The in-memory nature of the BTG state makes it hard to share
>>>> it with others.
>>>
>>> I suggest we dont do this for now. Keep it in memory, its actually very
>>> secure that way.
>>>
>>>
>>
>> OK.
>>
>>
>>>>
>>>> There seem to be two possible solutions:
>>>> (1) implement the BTG state as tables in a relational database. That way
>>>> other people can see it as well.
>>>
>>> this raises a whole raft of other problems as well (such as securing the
>>> DB etc). This could be a long term solution for a large scale
>>> operational system in a hospital.
>>>
>>> Maybe even a web service interface
>>>> could be provided on top of the database. This could work, although
>>>> actually having a (nice) GUI that displays everything so that it can be
>>>> reset by clicking on a link would require quite some work.
>>>> (2) Try to add a web service interface to the in-memory state. The
>>>> problem here is that I don't know how to do this, not without fiddling
>>>> around with the WSDL of the AIPEP (which I don't like to do). @George,
>>>> do you see a way out here?
>>>
>>> I dont like this since you are providing a back door into the PDP. It
>>> would be much better to use the front door and send a normal Authz
>>> decision request to the PDP, as in the design paper.
>>>
>>>
>>
>>
>> I wasn't planning on letting them reset the state via the interface, but
>> I have a 'working' solution now anyway, so I won't try to implement this.
>>
>>
>>>>
>>>> Do you think it is worth trying to pursue either of these approaches?
>>>>
>>>>
>>>> - I suppose that with 'the break the glass record is examined via the
>>>> audit bus' they just mean that a message indicating that the glass has
>>>> been broken was sent to the audit bus.
>>>
>>> correct
>>>
>>>> - I am not sure what 'the explanation is saved in the SAWS log of the
>>>> PDP' means.
>>>
>>> This is what we talked about before, that SAWS is integral to the PDP
>>> (through Log4J) and writes all the requests and responses to SAWS.
>>>
>>>
>>> It seems hard to decide what and what not to log to SAWS in
>>>> a general way.
>>>
>>> requests and responses only for operational running.
>>> Plus BTG reason from inside the obligation handler.
>>>
>>> I think the scenario should be changed so that we remove
>>>> SAWS from it, and indeed put the explanation in the email (as is done
>>>> now). Do you agree?
>>>
>>> I agree that the explanation should be in the email. I said this was
>>> cool when you first implemented it.
>>>
>>
>> OK.
>>
>>> But I also want to get SAWS into the PDP and implement the variable
>>> logging level through obligations (to alter the Log4J level - I thought
>>> you had done this once before)
>>>
>>
>> In principle, we can provide an 'audit trail' using SAWS if we would add
>> a 'audit.logger' to the code. At the moment I have added a simple
>> 'access.log' to the code that will log all the requests and responses
>> using Log4J. Adding a SAWS-appender here would already send this output
>> to a SAWS log.
>>
>> However, the 'altering the Log4J level' bit doesn't work at the moment,
>> although I did try to implement a 'Log4JAuditingObligation', I doesn't
>> quite work (and I am unsure whether it will ever work well). E.g when
>> using loggers based on 'subject-id' we will run into memory problems
>> eventually because once a Logger is created it can never be garbage
>> collected.
>>
>> Regards,
>>
>> Stijn.
>>
>>
>>> regards
>>>
>>> david
>>>
>>>>
>>>> Regards,
>>>>
>>>> Stijn.
>>>>
>>>
>>
>>
>

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************