[Ssc-dev] Authentication, Authorization and Architecture

[barbra]

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/13ea7bd3/attachment.html>