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@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 *****************************************************************