[OGSA-AUTHZ] btg scenario in D12.2

[David Chadwick]

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

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