[Ssc-dev] Authentication, Authorization and Architecture

[Harlo Holmes]

let's do another call tomorrow to go over these things. any time good for
you all?
On Mar 6, 2013 9:42 PM, "barbra" <blmack at gmail.com> wrote:

> hi
>
> some of what lee is proposing has come out of a discussion about how we
> can have a secure API and more complex authorizations. The API-focus is
> coming out of a few different needs:
>
> 1. IBA wants to seperate the file storage system from the
> intake/verification system between the phone and server. An API way of
> communicating between functionality seems like the most elegant way to
> modularize (and would allow us to be more flexible on our server front-end
> as well as with phone interfaces as well), as this functionality is
> currently all intertwined in the existing system.
> Out of Lee and my discussion today, it was clear that secure API calls
> between these modular systems could be largely based on the work already
> done that you mentioned Nathan. The different servers could follow the
> same/similar verification process.
>
> 2. IBA is requesting a fair amount of functionality outside of the scope
> of InformaCam
> (e.g., complex reporting, sharing with external clients, exporting
> submitted media, publishing on various outlets, etc.)
> Again, an API approach seemed like the best solution with the most gains.
> This we also considered OAuth as a good fit for. And it gives us a ready
> answer as these types of request will just keep coming...i.e., "yes, you
> can get that info through our API and use with x".
>
> 3. IBA is requesting more complex permissioning for the server-side of
> users, as well as more complex evidence logs (and more complex logs are
> required in ISO standard for digital repos)
> This led us to review SELinux and Fedora Repository which both have
> complex permissions engines involved.
>
> 4. General thoughts have been re-occurring on Guardian and IBA sides about
> having a "published" catalog of media derivatives (e.g., to media outlets,
> or for people who might be interested, etc.). This is something that
> actually Witness already does (though not managed completely with an IT
> system). Not a pressing needs, but something to consider as we refactor the
> architecture this time around.
>
> I think Lee can speak to the need he sees with Math folks and the
> permission sets.
>
> But I do think we needed to spend some time deciding how we would secure
> our "public-ish" and our internal system API(s), and go about building some
> permissions/authorization on the server-side.
>
> -barbra
>
>
> On Wed, Mar 6, 2013 at 9:20 PM, Harlo Holmes <harlo.holmes at gmail.com>wrote:
>
>> I think this part of the project refers only to properly authenticating
>> IBA staff members as they interact with already-submitted media. (like, who
>> on the IBA team has access to view encrypted metadata, and keeping logs of
>> who viewed what and when.)
>>
>> it should be outside the loop we established previously and has nothing
>> to do with the mobile client or its users.  But Barbra can explain more...
>>
>> Thanks,
>> Harlo
>> On Mar 6, 2013 9:03 PM, "Nathan of Guardian" <nathan at guardianproject.info>
>> wrote:
>>
>>>
>>>
>>> Lee Azzarello <lee at rockingtiger.com> wrote:
>>>
>>> >Nathan,
>>> >
>>> >
>>> >Can you describe the level of detail for authorization of roles from
>>> >client to server? I don't think I understand the scope of this project
>>> >not the requirements to ensure a chain of custody in a court of law.
>>>
>>> This is what the entire InformaCam IBA project has been doing for the
>>> last year. The Chain Of Custody issue is solved based on the signing and
>>> encryption Harlo has already implemented. You should be able to post
>>> informacam blobs into the public internet, as long as they have been signed
>>> by the submitters key and encrypted to the trusted parties key. We also
>>> have the file hash submission process that is again, already designed and
>>> implemented.
>>>
>>> The only roles there were ever meant to be were 1) known or unknown
>>> person submitting a report from their device and 2) trusted party receiving
>>> report and being able to unpack and verify integrity of report blob.
>>>
>>> I know we have added additional function to the server to allow
>>> searching and browsing of reports, but super complex roles and distributed
>>> computing authenticating mechanisms seems like we are way way out of any
>>> design goals I am familiar with.
>>>
>>> Harlo, Bryan - can you provide some clarity here? Are we getting pushed
>>> in directions by the IBA that I am not aware of?
>>>
>>> +n
>>> _______________________________________________
>>> Ssc-dev mailing list
>>>
>>> Post: Ssc-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>>
>>> To Unsubscribe
>>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>>         Or visit:
>>> https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com
>>>
>>>
>>> You are subscribed as: harlo.holmes at gmail.com
>>>
>>
>> _______________________________________________
>> Ssc-dev mailing list
>>
>> Post: Ssc-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>
>> To Unsubscribe
>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/ssc-dev/blmack%40gmail.com
>>
>> You are subscribed as: blmack at gmail.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20130306/c03a826d/attachment-0001.html>