A Full Security Overview: Project Firefly Guides
This post explores the security measures and features in Project Firefly. Also, check out our full breakdown of the dynamic architecture underpinning Firefly app, and get a look at the end-to-end user journey of a Firefly app.
When it comes to creating effective solutions to solve business programs, many enterprise developers know that building their own custom app to extend existing tools is the way to go. Project Firefly (now in developer preview) is a framework that provides everything a developer needs to build custom apps that extend Adobe Experience Cloud solutions. Of course, right up there in importance along with whether or not a custom app actually solves a problem, is whether or not it does it safely. We know security of your app is a top concern, and so we’ve built Project Firefly to be highly secure via:
- Application access controls — Control who can and cannot access your Firefly apps.
- Application security tools — Out-of-the-box features and support for building secure apps.
To learn more about the access and security controls built into Firefly, watch the video below and read on for more details. If you want to get started right away, check out the Firefly docs.
Defining application access in Project Firefly
A key aspect in keeping your app as secure as possible is defining who can access it. Who can access your Firefly app once it’s published within your org is defined by a few conditions. They are:
- The Experience Cloud organization that owns the app. Firefly apps are always owned by an Experience Cloud org, so business users need to be members of this org in order to access the app. If a user is a member of multiple Experience Cloud orgs, they can simply use the org switcher to access the relevant apps.
- The Adobe apps the business user has access to. The user needs to have access to all of the Adobe apps used by a Firefly app in order to access it. For example, if an app uses the Adobe Analytics and Adobe Campaign APIs, a user will need to have access to both of these Adobe tools to use the custom app. This ensures that data is never exposed to users that aren’t authorized. You can manage which Adobe apps a user has access to via the Adobe Admin Console.
The role of Adobe Identity Management Services
Also known as IMS, Adobe Identity Management Services sit between your enterprise end user and your Adobe solutions, handling all user authentication. When a user logs into Experience Cloud, IMS grants them access via a user token. This token is used by Project Firefly to identify which apps the user does, and doesn’t, have access to.
Application security in Project Firefly
In building Firefly, we’ve worked hard to ensure the out-of-the-box functionalities enable you to build secure applications with ease. There are three main avenues we take to ensure your Firefly apps are highly secure: the security of running your application in Adobe I/O Runtime, the handling of authentication to APIs in your back-end service, and ensuring you have secure access to your app’s data and file storage.
Security in Adobe I/O Runtime
Adobe I/O Runtime, our serverless platform, has itself been build with safety in mind. When your back-end service is running in I/O Runtime, it essentially exists as actions (standalone or orchestrated). When invoked, each action runs inside its own container. A container may be reused for the same action, but never for a new action or application.
When the action code is isolated within the container it does retain full access to the internet, so you can make calls to external services. Nonetheless, the code you write should always follow best practices to make sure it’s protected against malicious attacks. Check your dependencies routinely for any vulnerabilities.
All communications are secured by HTTPS. Communications from your functions to any other service should also use HTTPS, or another secure channel, whenever possible. Let’s take a deeper look at the back-end services available:
If you want your application to talk to Adobe Services, keep in mind that any Adobe API you use that accesses the services, data, or content of your app requires authentication and authorization through Adobe Identity Services. This usually follows OAUTH 2.0 protocol or JSON web token standards.
You can set up your credentials through the Developer Console to ensure this goes smoothly. These credentials will determine what content and data your application can access. To talk to Adobe Services within your application, you can include the IMS libraries prepared for you, which allow you to easily exchange credentials for an access token, and to cache the token.
Within your application, you’ll also be able to access any external services or APIs. While we may not have any native support for these, it’s thanks to the node.js community that we have many NPM modules to help generate your access token for these APIs.
File and data
Adobe provides out-of-the-box storage for files and data. In order to simplify your connection to this service, we have built libraries that can be used inside your app. Once you include the library, you can initialize it by exchanging your Runtime credentials for a token that grants you access to file and data storage. This token, granted through what we call Adobe I/O Token Vending Machine (TVM), is temporary and restricted.
In addition to the token, all the file and data storage is isolated and containerized by application on the service level. Your application won’t be able to access files and data stored by other applications.
If you’re an enterprise developer and you build apps (or want to build apps) that extend Adobe Experience Cloud solutions, apply to take part in our free developer preview. And continue to watch the Adobe Tech Blog for news, resources, and stories about Project Firefly and how developers across the globe are using it to create custom apps that improve business outcomes. To learn more, head over to the Project Firefly homepage.