[Ssc-dev] Authentication, Authorization and Architecture

Lee Azzarello lee at rockingtiger.com
Thu Mar 7 13:12:35 EST 2013 

Brian, Barbra, Carrie and myself just met. Indeed, there are two
distinct goals for the architecture. The first is a system with user
account and anonymous uploading. This is the "consumer" version. The
second is a system that is modular and can increase in complexity
based on the users needs. This is the "pro" version.

It's unrealistic to build the pro version now. Both agencies (IBA and
GLSP) will use the consumer version and we must stand by the features
of that system when it is delivered. At the same time, architecture
documents for the pro version will be drafted in as much detail as
possible. Nothing in these documents will be implemented until the
consumer version is delivered.

We agreed that there is room to bring in an expert in solving complex
authorization problems across distributed systems.

Regards,
Lee

On Thu, Mar 7, 2013 at 1:00 PM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
> I can try to join too
>
> .hc
>
> On 03/06/2013 10:21 PM, Lee Azzarello wrote:
>> 15 or 14?
>> On Mar 6, 2013 10:00 PM, "barbra" <blmack at gmail.com> wrote:
>>
>>> i can do 16:00 gmt.
>>>
>>> -barbra
>>>
>>> On Wed, Mar 6, 2013 at 9:57 PM, Lee Azzarello <lee at rockingtiger.com>wrote:
>>>
>>>> I think sooner.  Considering its 10 pm est and timezones, how is 16:00
>>>> gmt?
>>>>
>>>> Lee
>>>> On Mar 6, 2013 9:46 PM, "Harlo Holmes" <harlo.holmes at gmail.com> wrote:
>>>>
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>>
>>
>> _______________________________________________
>> 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/hans%40guardianproject.info
>>
>> You are subscribed as: hans at guardianproject.info
>>
> _______________________________________________
> 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/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info

More information about the Ssc-dev mailing list