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.

Sign me up!

Bintray Premium gives you cool new features such as private repositories, permission management, more storage and so much more. One of the biggest benefits of using a Premium account is the ability to create expirable, signed URLs for your repositories’ content.

Signed URLs you said? What’s that?

A signed URL is an obscure URL with a (potentially) limited lifetime. When your artifacts are published in a private repository, each artifact is hidden from unauthorized Bintray users. If you want to allow any Bintray user, or even or a non-Bintray user to download your package, you can generate a one-time unique URL with an option to limit its validity so that is expires after a certain amount of time. You can also revoke any outstanding URLs at any time.

How does it work?

When you become a premium user in Bintray, your account holds unique, internal, private and public keys. The URL you decide to sign, will be encrypted and decrypted with those keys.

Let’s say user “srubin” has a private repository called “artifactory”.

This private repo contains a file, “artifactory.rar”, that protected from public access. Only authorized users can download it using the standard download link, which is:

Bintray Premium Link Signing

Bintray Premium Link Signing

To allow a one-off download of this file we will generate a signed URL for it using a simple REST call:

curl -XPOST -usrubin:APIKEY ""



By default, this URL will be valid for 24 hours, but we can change that by specifying an expiry time in a simple JSON configuration document:

curl -XPOST -usrubin:APIKEY  -H "Content-Type: application/json"  -d "{\"expiry\":7956915742000}""



More details about this API can be found in our documentation.


Signed, expirable URLs is a cool new feature of Bintray. It allows you to automate the generation of one-off download URLs and distribute them to any end user.

We will soon extend this feature to make it even cooler. Keep following to see what we have in store for you!

Feel secure with SSL? Think again.

Recently, we’ve heard a lot of discussion about the trust we place in public binary repositories. For example, Maven Central, a popular legacy repository maintained by Sonatype, was recently compromised by a successful MITM attack. In response, Sonatype set up an https access to central (removing the demand for a $10 donation to the Apache Foundation for using SSL). This has no impact on millions of maven installations in the world, which will continue access Maven Central via http unless manually reconfigured, but the interesting question is – is that enough?

While SSL is important in guaranteeing the integrity of downloaded files, it doesn’t say anything about the integrity of the files in the repository itself. The only(!) verification mechanism in the repository itself that Maven Central and other legacy repositories suggest you blindly trust, is the set of signature files uploaded with the files. Interestingly enough, modern repositories such as, npm-registry and Bintray don’t force you to sign your files at all. Let’s try to understand why.

Here’s tl;dr if you need one.

Is SSL access enough for us to feel secure?

To answer this question, let’s consider Maven Central. This is a repository that works with SSL and “secures” the files with PGP signatures. In theory, these signature files strongly identify the signer (assuming that both the jar files and the signatures are served over SSL). But do they really?

Let’s see how it works:

  • The author uses a gpg tool to generate a keypair for identification.
  • The author then uploads the public key to a trusted key server (one of MIT, SKS OpenPGP Public Key Server or PGP Global Directory).
  • Anyone who wants to download a package and verify its integrity runs a signature check against one of the servers, and gets the unique and verified identity of the author.

Is it so?

Let’s run a couple of experiments, and see how securely the “secured” Maven Central is really maintained.

Here’s one of Sonatype’s latests jars: nexus-core-2.8.1-01.

Let’s download it see what’s the signature says, after importing the signer’s public key:

>gpg nexus-core-2.8.1-01.jar.asc
 gpg: Signature made 05/27/14 18:00:54 Central Daylight Time using DSA key ID 8DD1BDFD
 gpg: Good signature from "Sonatype, Inc. (Sonatype release key) <>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: 2BCB DD0F 23EA 1CAF CC11  D486 0374 CF2E 8DD1 BDFD

Whoa! What happened?! “There is no indication that the signature belongs to the owner”?!

Wait a second. Does that mean that anyone can generate a keypair for Sonatype, Inc. “(Sonatype release key) <>” pretending to be the Sonatype release team?

Here’s an amazing picture for you:

Click to see

Hiene writes code


According to the “trusted” key server, all those signatures belong to the German poet Heinrich Heine. Well, I would say that’s quite unlikely since he passed away quite some time ago1.

Let’s run a couple of more tests (go figure, maybe it’s only Sonatype who can’t generate a “truly trusted” signature):

Here’s a signed Eclipse artifact:

 gpg: Signature made 05/18/14 12:54:52 Central Daylight Time using DSA key ID A7FF4A41
 gpg: Good signature from "Benjamin Bentmann (CODE SIGNING KEY) <>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: BA92 6F64 CA64 7B6D 853A  3867 2E20 10F8 A7FF 4A41

Same again!

Here’s Oracle’s OpenJDK tool:

>gpg jmh-core-0.9.5.jar.asc
 gpg: Signature made 07/24/14 13:53:36 Central Daylight Time using RSA key ID 060CF9FA
 gpg: Good signature from "Evgeny Mandrikov (CODE SIGNING KEY) <>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: A413 F67D 71BE EC23 ADD0  CE0A CB43 338E 060C F9FA

Whoa, who’s Evgeny Mandrikov? An Oracle employee? Nope. Why does he use gmail? Let’s see, maybe Sonatype pre-verified him when they gave him access to Maven Central? Did he establish a relationship with Oracle or something? Nothing, not a single question. “I have nothing to do with Oracle, but still want to publish OpenJDK artifacts!” “OK, go ahead”. Can you trust him to provide you with authentic OpenJDK artifacts? Not sure2.

You get the picture. You can’t trust those self-generated key-pairs. And the Trusted Key Servers themselves acknowledge it! Here’s a quote from the Key Verification Policy of PGP Global Directory:

…there is always a risk that the verified key in the PGP Global Directory is not actually owned by the person who appears to own it. While the verification mechanisms in the directory are suitable for many purposes, you should endeavor to use additional mechanisms…

That’s exactly what modern repositories, like Bintray and GitHub do. But we’ll get to that shortly.

But what about WoT?

Ah,” one can say, “that’s because you don’t have a clue about how pgp signatures work! You need to establish a Web of Trust with the signer and voila, the message is gone!

While technically correct, this makes very little sense in our context.

WoT works for the original usage of pgp signatures – authenticating content from people that you know directly, or indirectly through your contacts. For example, it works great for signing emails. You are likely to get email from people in your first, second or third circle of connections, but almost never from complete strangers. With packages from an Internet repository, this concept breaks completely. Chances that a developer personally knows the creator of a package, even if its indirectly to one or two levels, are close to zero. Same works for the creators of a package. As an author, you have no idea who is going to use your package. You can only hope that they’ll be a bunch of strangers that you don’t know :-D.

I am intrigued. Show me how can I maliciously upload a forged artifact to Maven Central without even using MITM!

Tedious, but straight forward:

  1. Invent a fake identity (with a fake, but functional email address).
  2. Generate a keypair for it.
  3. Upload to a public key server (that’s where your email is needed).
  4. Follow the guide. The trickiest part is faking a story about your artifact to get your account set up in through the Sonatype JIRA. Well, be creative!
  5. Within a couple of hours (or days) your artifact will get to Maven Central. If the description you invented  looks realistic enough, no questions will be asked. Somewhere during  the process of uploading and releasing files, Sonatype will check that the signatures with which you signed your artifacts match the email you used for your account. But of course, they match.
  6. Mazal Tov! Your fake artifacts are now in Maven Central. From there they will be securely(!) downloaded over SSL to your victim computers by Maven.

Easy? Well, not really. Looks like the MITM attack was easier. But that’s what it takes to add a jar to Maven Central.
Doable? Absolutely.

But how is Bintray different?

Well, we realize that in the modern world, where identity theft is one of the more popular crimes, you can’t blindly trust an online identity. So, like many other services, we recommend that you assess how trustable any particular content is (a jar in our case), based on the credit the community gives to the Internet identity of the author.

Here’s what I mean:

Let’s say you want to download Groovy. Here it is. Let’s see how can you establish trust in Groovy binaries:

  • You can see the links to a website and GitHub.
  • You can see that this package belongs to an organization: Groovy. You can clearly see the list of members, and check each and every one of them.
  • Here’s Guillaume Laforge.
  • Check out his twitter account – almost 8.5K followers.
  • Here’s his blog, all around Groovy.
  • LinkedIn? Looks good.

So, can you trust him? Probably. He’s an admin of the Groovy organization, so his reputation is the guarantee that the organization and the files in it are authentic. You’re good to go. Or not?

That’s up to you! We give you the information. You decide if you can trust it or not.

 But Maven just goes out there and brings stuff!

To create a safe build you must use an in-house binary repository manager:

  1. Install it.
  2. Configure a “dirty” and a “clean” repository.
    1. The dirty repository should be able to proxy a remote source of artifacts that gives you a good insight on artifact producers’ identities (not just a pile of files with self-generated signatures).
      Consider proxying Bintray’s JCenter instead of Maven Central. JCenter is a superset of Maven Central, so finding packages won’t be a problem.
    2. The clean repository is a local repository with no Internet access.
  3. Configure your build tool (Maven?) to be able to build against either of them.
  4. Use a “sandbox” (e.g. a vm) to run a “dirty” build against the dirty repository. Its cache will be populated with all the artifacts needed for the build.
  5. Examine the identities of the publishers of those artifacts (remember to select a binary repository that can generate a list of dependencies used for every build) against the information you have about them (as you understood, it’d better be more than self-signed signatures).
  6. Promote the artifacts that you trust to the clean repository (remember to select a binary repository with deduplicated storage that gives you free and immediate “move” operations).
  7. Now you can safely build against the clean repository!

Here’s the summary (a.k.a. tl;dr):

  1. SSL is an important way to verify that the files you trust get safely from a server to your machine.
  2. Don’t let SSL give you a false sense of trust in the origin or author of the files.
  3. Don’t blindly trust self -issued signatures. One can generate a signature for any identity, sign any file with it and upload it to Maven Central.
  4. Go with a platform that enables and encourages web identity verification. Check the author and decide for yourself.
  5. Use a binary repository manager to discover and control the artifacts needed (and select it wisely).

1A gpg tool to work with pgp signatures was developed in Heinrich Heine University of Dusseldorf. In honor of the late poet after which the university was named, all defaults in the tool were initialized to Heinrich Heine, with the expectation that people would replace them their own details. Apparently, that didn’t work. People just enter-enter-enter through the settings generating dozens of key-pairs for the poor German, illustrating the absurdity of  “authentic”, self generated key-pairs.
Thank you, Heinrich!

2Actually, you can. Oracle do not distribute binaries of OpenJDK, and Evgeny volunteered, and was empowered by OpenJDK committers to do it for them.
But can you know without being personally familiar with Evgeny?! No, you can’t.

Fight Crime with GPG

So you deliver your awesome library to hundreds of users each day, but they’re a tough bunch and they’re all like:

“Hey man, we gotta see some ID”

So you kneel to the whims of the rabble; you generate your GPG key pair and sign each artifact you deliver, because hell if you’re gonna let someone miss out on your superb code

And let there be no mistake – this road means pain, brother.
Wanna use some organization-wide key pairs? How do you plan to safely share them around?
Wanna make sure all products are properly signed? Good luck configuring each and every of your hundred or so builds!

But this is where Bintray swoops in like The Dark Knight, man! To save you from those GPG signing street gangs!
Because unlike the technological promises made by the second millennium (flying cars and whatnot), Bintray took an oath and will do anything it can to help you deliver!

Damn straight; Bintray can now (optionally, only if you want it to!) manage your GPG keys and sign your Maven artifacts for you, so that you have proof about the authenticity of your goods.
All you’ve got to do, is generate your GPG key pair and associate it with a subject (be it your user or your evil organization):


Your public key will be available for others to download right from your public profile page.

Select a repository signatory:
And you’re good to go.
Sign artifacts by deploying through the UI or by using one of the available REST-API commands.

“But Bintray,”

you might ask,

“How can I trust you with my keys?”

“Well son, we here are good people… “

Bintray might answer; but it won’t, because it’s not a sentient being.
But you know what’s better than sympathetic answers? actions!
Bintray also supports password protected key pairs; this means that by issuing a single command over a secure HTTPS connection, you can sign your precious artifacts using a pass-phrase. In any case, we encrypt your private key. It’s safe with us.


Still don’t trust us with your keys? It’s cool, we understand; the world is a dangerous place and we’ve still got you covered!
Bintray now keeps a stock built-in key-pair so that it can auto-sign every file you upload.
To apply, edit your repository’s settings and select GPG sign uploaded files using Bintray’s public /private key pair:

So there you have it; enjoy another revision of this fine binary distribution platform.
Peace out