Shibboleth authentication to a RESTful API from mobile, curl, etc.

[Cantor, Scott]

On 4/3/15, 9:29 AM, "Philip Durbin" <philip_durbin at harvard.edu> wrote:

>
>The API in question is for retrieving one's API token for use in an
>Android app. For non-Shibboleth users, I plan to have the Android app
>prompt you for your username and password, retrieve your API token on
>your behalf[1], and use that API token for subsequent requests such as
>searching and downloading data.

You would have to do the same thing with a SAML IdP if you don't intend to use a browser. You can't avoid the credential collection step in a non-browser client scenario. If you don't want to prompt, you'll have to launch a browser to handle it.

>But what about Shibboleth users of my Android app? I could tell them
>to copy and paste their API token into the Android app[2] but I'm
>hoping to provide a better user experience than that! Ideally the user
>experience would be on par with the non-Shibboleth account holder
>experience described above. (Shibboleth users would have an extra step
>of selecting from a list of Identity Providers, of course.)

In a non-browser client, that really should be provisioned somehow ahead of time, rather than selected in-band, but that's not a well-defined thing. Most uses tend to be single-IdP and so things get baked in. There's not much state of art in handling multiple IdPs or how to make sure they can be trusted (i.e., commercial TLS is broken, so relying on that is a disservice to all of your users). I see zero value in turning SAML metadata into JSON for servers, but for clients it probably has significant value.

>Searching for "android shibboleth" yields questions[3] about how to
>accomplish what I'm talking about and mention of something called
>"Enhanced Client or Proxy" (ECP)[4].

Well, as I say, ECP does not absolve you of handling the credentials in the client. From the user PoV it would look identical.

>Ohio State University seems to be using Shibboleth with mobile apps:
>"The current OSU Mobile application supported on iOS and Android
>includes native implementations of ECP client code. The OCIO is
>working to make that code publically available, but we have no ETA on
>that."[6]

I've asked, many times, it's not happening AFAICT. I'll have to update the page.

>It looks like SSO with native mobile applications was discussed[7] on
>this list last summer, with advice from Scott Cantor to use ECP or an
>embedded browser. (For a better user experience, I'd rather not use an
>embedded browser.)

Well, embedded browsers are not the right answer, they mask all the security signaling. But using the browser full frame is basically what everybody seems to want to do, and is in some opinions more usable than the other options. One reason is that implementing orchestrations that turn multiple single factors into a real MFA tend to need a web UI.

>Am I on the right track? Any pointers? Any recommended open source
>mobile apps that support Shibboleth I can look at?

I doubt there's anything more than you found, and all the ECP client code we know about is linked into the wiki.

Though just because code hasn't changed, that doesn't mean it's bad. ECP has been extended but the original profile hasn't changed in 10 years because it wasn't broken. If the code works, it works.

What you want is to hide any and all details like that inside an HTTP client facade. The calling app shouldn't care about any of it (nor should the called service), and you should be able to swap in different mechanisms any time you want.

-- Scott