[Ssc-dev] Authentication, Authorization and Architecture

barbra blmack at gmail.com
Thu Mar 7 15:05:24 EST 2013 

more complex not "complex permissioning" in terms of what IBA is asking for
(in the short-term). currently its an all or nothing setup on the server.
and they want to have some variation in user rights against the media
files. but, i agree this is not something that can be met in the short-term
or with this initial piece of their funding.

also, if we are building out an API with some form of access control it
will require some complexity. However, the complex permissioning that I
think Lee was referring to was probably coming out of our discussion after
looking at Fedora Repository (which is a digital archives repository
middleware), and our review of SELinux as potential ways to make a secure
API. Fedora repository has a fairly complex authorization model, and is
somewhat of a standard in the digital repository field. It allows for the
detailed logs, and very granular access control on all resources.

Also, just to clarify a bit, the API research that Lee and I were
considering was not something we saw being completed by the end of this
month :-)

On Thu, Mar 7, 2013 at 2:56 PM, Lee Azzarello <lee at rockingtiger.com> wrote:

> I didn't have any information about the budgets for individual
> clients. I thought InformaCam got a $400k grant from the Knight
> Foundation.
>
> -lee
>
> On Thu, Mar 7, 2013 at 2:48 PM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
> >
> >
> > On 03/06/2013 09:42 PM, barbra 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.
> >
> > Has the IBA provided a scheme for this complex permissioning?  If they
> need
> > something complex here, they should start by providing a detailed scheme
> of
> > what they want implemented.  Also, wasn't the IBA funding only $25k? Or
> is
> > there more now?   This would be way out of scope of a $25k project, on
> top of
> > all the other work that has been done.
> >
> > .hc
> >
> >
> >> 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
> _______________________________________________
> 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/20130307/3a3a9a29/attachment-0001.html>

More information about the Ssc-dev mailing list