Securely Onboarding Colleagues through SAML Authentication

bintray_saml280x215.pngOnce you’ve created your Bintray account, getting your colleagues on board with permission-based access to your organization’s content is not always so easy. You want to use the most secure authentication available, so why can’t you use your corporate SAML server to authenticate your users?

The answer is, now you can.

If you configure your Bintray organization with the details of your SAML server, your colleagues can simply log in using their corporate SSO credentials, and they’re automatically included in your organization. So, not only are you using the most secure authentication your organization has to offer, you’ve also made it easy for your colleagues to get on board.interacting_saml_config_blurred

Now, you can make sure each user is assigned the right permissions by adding them to the corresponding Teams through the UI. That takes care of your colleagues and teammates, but what about external contractors or customers to whom you want to give access? They can’t be managed with teams and permissions since they’re not part of your Bintray organization  (and may not have a Bintray account at all). The answer is to use entitlements defined through the REST API giving them access according to a specified scope – these are what we call “scoped users”. More about that in a future post coming soon.

IP Restriction with White CIDR and Black CIDR

IP restrictionImagine this scenario. Your flagship product is doing OK; you’re getting downloads. Nevertheless, increasing sales is always a top priority, so you decide to create a free OSS version to boost usage and generate more awareness in the market. It’s also a great product, free to download, and is a great teaser for the upsell to your commercial version. So you upload the OSS version to your organization’s public repository on Bintray. After a while, you check its stats and are delighted to see thousands of downloads, and yet, there’s no buzz. If so many people are downloading your package, why is nobody talking about it? After checking your logs, you discover that most of those downloads you were so happy about are from the same set of IP addresses.

Someone is reverse-spamming you, and you need to block them.

Geo-Restriction could do the job, but then you don’t want to restrict whole countries at a time. You need something more targeted. Bintray’s new capability for IP restriction will do the job.

IP restriction is very similar to geo-restriction, only instead of defining your whitelist and blacklist as countries, you define them as a range of IP addresses using CIDRs. This gives you much more control letting you allow or block download at any level of granularity down to a single specific IP address. Whatever IP those bots are operating from can now be easily blocked so you can get the real download statistics you were interested in.

You can define your CIDR whitelist and blacklist through Bintray’s REST API or in the Edit Repository page.

IP restriction

Note that if there are any overlapping IPs, (i.e. IP addresses that are included in CIDRs that are in both the whitelist and the blacklist), then blacklisting them takes precedence. And if you accidentally list the exact same CIDR in both the whitelist AND the blacklist, Bintray will catch that and issue an error.

Ready to use IP restrictions? Get a quote for an enterprise account and ask for a free trial.

Automated EULA-protected Downloads

BINTRAY EULA280x215One of the great features of a Bintray Enterprise account is the ability to present a EULA when a user downloads one of your Products. That works well for the general case when the downloading user is a real person who can go through the Bintray UI and physically accept the EULA for publicly available content. This is something we discussed in a previous post. But what if you want to be more selective about who can download your content, and you want to limit it to a defined set of people? And what if those people want to download your content using automated scripts? And what if they don’t even have an account on Bintray? Those are a lot of hoops to jump through, but Bintray now offers a solution to this common circus of circumstances.

You can now offer automated EULA-protected downloads through the REST API to any pre-defined set of users, whether they have a Bintray account or not.

Here’s how it works.

  • You create an entitlement which gives access to your product and then you provide the corresponding access key to your user.
  • Your user browses to a specially constructed Bintray URL
  • Bintray displays a login screen where your user enters the access key as the username, and its password
  • Bintray then displays the EULA for your user to accept.


From now on, any REST API call that includes the access key you provided to your user will succeed unhindered by the EULA, since the EULA has already been accepted using that key. In other words – automated EULA-protected download. And who gets this privileged access? Not everyone. Only those who are privileged enough to receive the access key you created to protect your content. In other words private, automated EULA-protected download.

Protecting your products with a EULA has never been easier, whether you are offering something for public download, or whether you want to expose private content to a defined set of users.



Developing for OpenWrt? Bintray Has an Opkg For You

Opkg280x215OpenWrt is typically associated with network routers and similar equipment, and indeed the official OpenWrt website lists overs 1200 devices on which it runs. Network routers may sound boring (well, to some of us), but as the Internet of Things (IoT) continues its crusade around the world, many people don’t know that OpenWrt is also used on other devices such as phones, robots, sensor networks and more. To accommodate these more glamorous devices, and implement their cool features and functionality, and to give a network router an edge beyond the basic functions, you need a bit more than the Linux kernel on which OpenWrt is based. This good stuff comes in the form of over 3,500 Opkg packages which are available for download from public repositories. The good news is that JFrog Artifactory and JFrog Bintray together offer developers an end-to-end solution to manage their Opkg packages from development through to distributing them automatically to all those routers and robots alike.

While you can use Bintray to distribute your Opkg packages independently of Artifactory, using Artifactory for your OpenWrt development, can speed up your development cycles. For example, Artifactory support for Opkg gives you local repositories for the components you are developing, remote repositories to proxy remote ipk packages and get all those dependencies you need, and it even handles GPG signatures to verify packages. Once your packages are ready to go, use Artifactory’s Distribution Repository and push them to Bintray.

Bintray support for Opkg lets you work transparently with the Opkg client to resolve packages from Bintray and to upload them for distribution. As a mature and universal cloud platform for the distribution of software, Bintray can deliver software updates to users and devices alike over fast CDN, with advanced security features like access entitlements, detailed download stats and logs and more.

Uploading files is easy as 1-2-Oh-there-isn’t-even-a-3

  1. Create an Opkg repository and package in Bintray
  2. Upload your “ipk” file using Bintray’s REST API.
    For example, to upload kool-bot-utils to my robot-utils package in repository opkg-distributions with cURL, I would use:
curl -T kool-bot-utils.ipk -ujaycroaker:myapikey

Once your file is uploaded, Bintray will calculate the repository-wide Opkg metadata to maintain compatibility with the Opkg client.

If the version specified in the command don’t exist, Bintray will create it for you. And of course, you can do all of this through Bintray’s REST API, or through the JFrog CLI and in that case, you can do the above and publish the file in a single call.

Downloading is also a snap

The Opkg client works transparently with Bintray. You just need to define Bintray as a feed in your opkg.config file:

echo 'src bintray-feeds' >> /etc/opkg/opkg.conf

Now you just install …

opkg install robot-utils

And if you need authenticated access to the repository, you can just add your Bintray credentials to the config file:

echo 'option http_auth jaycroaker:myapikey' >> /etc/opkg/opkg.conf

You don’t even need to memorize these lines. Bintray has a cool Set Me Up feature for every repository type that displays these code snippets for you to copy and paste into your scripts.


So if routers, robots, and OpenWrt are what make your day, have a look at Bintray’s support for Opkg. Need private repositories? Check out Bintray Premium where you can use signed URLs and access entitlements for fine-grained control over who (or what) can download your ipk files. We envision the day when, not only routers and robots, but all devices get their software updates from Bintray.


Geo Restriction Lets You Control Where Your Content Can Be Downloaded From

geolocation1When you publish software for distribution on Bintray, you generally want to give it as wide a reach as possible and expose it to as many potential users as you can. But there are also cases in which you have to restrict access to certain countries. For example, government security or export regulations may forbid you from doing business with certain countries, or your own company may even restrict your particular organization to distributing your software in your own local region of the world. This is where Bintray’s Geo Restriction feature saves the day.

White lists and black lists

Bintray’s Geo Restriction feature works by letting you define a whitelist or a blacklist per repository. If you create a whitelist, only users from countries entered in the list will be able to download software from the repository. A black list works the opposite way; users from countries in the list are forbidden from downloading software. Bintray determines where a download request is coming from by passing the request IP to a GeoIP provider who determines the country from which the request originated. Then, if a Geo Restriction is applied to the target repository, Bintray will make sure the request can be honored according to the whitelist or blacklist defined. For download requests from countries restricted from accessing a repository, Bintray will respond with an error.

Geo Restriction is available for repositories in an Enterprise account. Gold account users can also see how this feature works, but are limited to one country in the list.

It’s so easy

You can define a whitelist or blacklist by selecting the Geo Restriction tab in the Edit Repository page for each of your repositories. Note that you can only edit the repository if you own it, or if it’s owned by an organization of which you are a member and have the required authorization to do so.


Geo restrictions come first

A Geo Restriction overrides any other form of “permission” in Bintray. In other words, even if a user is a member of your team and has “permission” to download a file, or even if you’ve provided someone with a signed URL or an entitlement  to download a file, if their request comes from a restricted country, it will be blocked.



Keep Your Secrets Safe by Serving Encrypted Files

encrypted_280x215aOnce you have uploaded your content into Bintray private repositories, it’s pretty safe through Bintray’s management of users, organizations, and teams. But what happens when you need to send a private file to someone else? Signed URLs give you an easy way to do that. Just generate your URL signing key and use the URL signing API call to create the URL. You can even make the URL valid for only a limited period of time. Now all you need to do is send the URL to the right person.

But what happens if the URL or the downloaded file gets into the wrong hands? Suddenly the file containing a license key/sensitive company information/anything-else-you-badly-wanted-to-keep-private is exposed..

Well, worry no more.  Bintray can now protect you from that kind of unwanted exposure.

On-the-fly file encryption

Bintray can now encrypt your file, on-the-fly, before it is downloaded through the signed URL. It works like this:

  • Upload your file (either manually through the website or using the REST API) into one of your private repositories.
  • Now you can generate the signed URL which will download the file.
    Nothing new yet, but here’s the thing.
    Now you can also attach a secret to the signed URL and tell Bintray to encrypt the file before it is downloaded. Bintray uses AES 256 CBC encryption for which you can provide your own secret key or ask Bintray to create one for you.
  • Now you can provide your customer with your secret through an alternative communications channel.
  • Once your customer has downloaded the file, they can use the secret key to decrypt the file using an OpenSSL command line. In other words, they need both the signed URL and the secret key.

Let’s See It In Action

Let’s assume we have a top secret “message.txt” file in a repo. We’ll use the REST API to create the signed URL:

curl -X POST -H "Content-Type: application/json" --data '{"valid_for_secs": 3600, "secret" : "my secret"}'

200 OK
"url": ""

If you don’t supply a secret, Bintray will create one for you and return it as an Http header: X-Bintray-Secret. Note that for that extra bit of security we limited the validity of the URL to 3600 seconds.

Your customer can now download the file from the returned URL:

curl -o message.txt ""

You can choose any secured way to send the user the secret. For example: phone or text message.

Now, to decrypt the file, your customer can use OpenSSL:

$ openssl enc -aes-256-cbc -d -in <encrypted file name> -out <decrypted file name output>

The tool will prompt your customer for the secret and then proceed to decrypt the file.

That’s how you keep your secrets safe. Enjoy!







Who needs a EULA if nobody reads it?

bintray_eula_products_blogpostAs long as you’re distributing public open source software, you don’t need a EULA. Just choose from the over 100 open source licenses Bintray offers to get the level of protection you want. Once you move to distributing commercial software, you need a EULA. This is the contract that you make with all of your users when they download your software from Bintray. Without a EULA, you’re exposing yourself to lawsuits and unmitigated copying and redistribution.

Now, we’ve all seen EULAs. Whether they’re entitled “Terms of Service”, “Terms and Conditions”, or “Here’s what you can and can’t do with my software”, essentially, they are the same. They usually pop up early on in the installation sequence of any new piece of commercial software we install. And I can tell you, with 5-nines of certainty that most of us just click “Next” without reading them, and complete the installation. But there is a breed of people who actually DO read EULAs. They are usually sequestered in some corporate enclave, and it’s their job to make sure that the company they represent can accept the contractual obligations you set forth in your EULA. Yes, these are the company lawyers. Without their “OK”, your potential enterprise customers will not use your software.

Now, as smart as lawyers may be (or not), if your EULA is hidden somewhere deep under /etc/this/that/and/the/other, it’s going to be difficult to find. There’s no reason to make this difficult. Bintray gives you an easy way to expose your EULA through Products.

Bintray Products and EULAs

Say you developed your “packageOfTheCentury”, and, naturally, you want to offer it to developers on different platforms. I.e., you might have your debianPackageOfTheCentury, nugetPackageOfTheCenutury, npmPackageOfTheCentury…and so on. Since all these packages represent the same product, just for different packaging formats, you will want to apply the same EULA to all of them. This is where Bintray Products come into play. Products are available with a Gold or Enterprise account, and let you collect all the packages under one roof as a single coherent offering, making it easy for you to manage. It’s also easier for potential users to find your single product rather than searching for all its components separately, and any update you make to any of the constituent packages in your product is automatically reflected as a new version of the product itself. But the biggest benefit is that you only need to assign a single EULA to your product, and it applies to all of its constituent packages. And the beauty of it is that your EULA protects your product, for both authenticated and anonymous users, before it’s even downloaded, rather than being embedded inside the packages. That also means that it’s easy to update online as any of the constituent packages are updated with new versions. 

Creating a Product is easy.



And once your product is created, and you’ve entered its basic details, it’s easy to add packages to it.


You don’t even have to change your product’s version manually; it is automatically derived by Bintray any time the version of one its constituent packages changes. And if you really want to, you can assign a different EULA to different versions of your product as needed.You don’t even have to change your product’s version manually; it is automatically derived by Bintray any time the version of one its constituent packages changes. And if you really want to, you can assign a different EULA to different versions of your product as needed.

Product Versions


All About Bintray EULAs

With a Bintray Enterprise account, you can manage all of your EULAs in one place and set a default EULA to be assigned to all new versions of this product that are created.


You can create a new EULA at any time using Asciidoc, Markdown or free text.

Create a New EULA

And once you have a EULA assigned to your product, if anyone (even an anonymous user) tries to download a file from one of the packages in your product, they will have to accept your EULA first. In fact, the download URL provided by Bintray for any of the packages in your product will first pop up the EULA and require the user to accept before proceeding with download. That means you can provide a EULA-protected download link from any other app. Just hover over the package in your download list to see it.

Download URL with EULA


Why don’t you try this one to see how it works. Here’s what you should see.

Accept EULA


By collecting the different packages you are offering under a single product, governed by a single EULA, you’re protecting your interests, making things simpler, and reducing your (and your customers’) legal costs. Can you think of any better way to protect your IP and keep both your lawyers and your customers happy?

Read all about managing products and EULAs.