Winchester, MA The Fedora Futures team has completed the third sprint within the "Beta Phase" of Fedora4 development. The work of this and each sprint is planned and completed thanks to the contributions of Fedora stakeholder institutions which allocate developer time. If you would like to be involved with Fedora4 development, please send an email to Andrew Woods email@example.com, or the Fedora Steering Committee firstname.lastname@example.org. If you have comments on the work from this sprint, please also send an email or comment directly on the wiki. Contributing your institution's descriptive use case(s) to the wiki  is particularly valuable in informing ongoing Fedora development.
Read the the Sprint B3 summary:
About Sprint 3, Beta Phase
Osman Din - Yale University
Michael Durbin - University of Virginia
Greg Jansen - University of North Carolina, Chapel Hill
1) Authentication and Authorization
In the ongoing effort to create a flexible yet simple Authentication and Authorization implementation, this sprint has moved the initiative forward by creating an example policy decision point (PDP) and policy enforcement point (PEP).
This first implementation step leverages the underlying ModeShape authorization framework  to protect objects and datastreams at the repository-level versus at the REST-API-level.
This approach ensures that repository resources are protected irrespective of whether they are accessed from a web-based user or via a direct application integration with Fedora's Java library.
ModeShape's authorization framework allows for integrating custom Authentication Providers. This sprint adds two draft implementations:
- PDP for Servlet credentials
- PDP for OAuth (placeholder)
The pattern established by the Servlet credentials PDP is to plug in a custom PEP so that when a request for a repository resource is directed to the PDP by ModeShape, a custom PEP is invoked to make the actual access decision. The custom PEP can be written to consult:
- policies stored within the repository
- policies stored in an external system
- something else
More description of the Authentication and Authorization design  and configuration  can be found on the wiki.
2) Fedora3 to 4 Upgrade
Being able to upgrade an existing Fedora3 repository to Fedora4 is a must. Although there are significant features which are found in Fedora3 that have not yet been implemented in Fedora4, there is a short-term value in enabling institutions to upgrade a non-production Fedora3 repository; namely, to give a more concrete context for evaluating the in-progress capabilities of Fedora4.
This sprint added the ability to "project" a Fedora4 installation over one or more legacy Fedora3 repositories. You can now configure Fedora4 to expose the contents of a Fedora3 repository as if those objects were native to Fedora4. In addition to making the implementation more robust, next steps will include the ability to actually copy the Fedora3 objects into Fedora4-managed storage.
- Ideally, the movement of the datastreams will not be necessary in this scenario
More description of the Fedora 3 to 4 Upgrade design  and concept mapping  can be found on the wiki.
3) Backup and Restore
This sprint added the ability to backup your Fedora4 repository and subsequently restore from a previous backup.
Both the backup and restore processes can be invoked via an HTTP call.
The result of the backup operation is the placement of binaries and complete metadata/properties of repository objects into a designated backup directory.
More description of the Backup and Restore functionality, usage, and exported representation can be found on the wiki .