How to get token via API from IBM App ID backed by SAML? - ibm-cloud

Question

I'm trying to use App ID to do user authentication/authorization against a service running in Kubernetes from a CLI tool.
I've provisioned App ID and configured SAML identity provider. I added an application and got the tenant id, client id, and client secret. I also added the appid-auth annotation to the Kubernetes ingress definition.
According to the documentation here https://cloud.ibm.com/docs/services/appid?topic=appid-obtain-tokens, it should be pretty strait forward via curl, but I'm getting Error - cloud directory is OFF.
Here's an example with the credentials X'd out.
$ curl -iX POST \
> https://us-south.appid.cloud.ibm.com/oauth/v4/XXXX/token \
> -H 'Authorization: Basic XXXXXXXXX' \
> -H 'Content-Type: application/json' \
> -H 'Accept: application/json' \
> -d '{"grant_type":"password","username":"testuser#ibm.com","password":"testuser"}'
HTTP/2 403
date: Tue, 04 Jun 2019 17:20:54 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d8fb55f6b30555b81f64b3c3e40bbf8f71559668853; expires=Wed, 03-Jun-20 17:20:53 GMT; path=/; domain=.us-south.appid.cloud.ibm.com; HttpOnly
x-dns-prefetch-control: off
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15552000; includeSubDomains
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
surrogate-control: no-store
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
pragma: no-cache
expires: 0
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4e1b948028aec1cf-IAD
Error - cloud directory is OFF
If I use "grant_type":"client_credentials", it returns get an access token, but I need an identity token so the application can do authorization based on the user.
I've tried using the 'web' version in the ingress definition, and the web redirect works fine. So I know SAML is configured correctly.

Answer 1

You're mixing few different concepts here.
SAML authentication works by presenting a Login UI to user. User needs to fill email/password (or whatever credentials are) and then be taken back to the application. Bottom line here is SAML authentication workflow implies human user that can interact with browser in order to enter credentials. In order to achieve SAML federation through OpenID Connect (the protocol App ID is based on), a grant_type called authorization_code is used. This workflow also implies presenting user with login UI. Since SAML authentication cannot be used without presenting user with a UI you cannot use API only approach in order to authenticate users. With SAML you have to use grant_type=authorization_code, which will only work properly in browsers (unless you do html scraping, which is not recommended).
"grant_type=client_credentials" works differently. It is designed for non-user-interactive scenarios, where you do not have human users involved. SAML is used for authenticating users, client_credentials is used for authenticating applications/services.
Check out the Technologies Under the Hood video in App ID Tutorials on youtube, it explains the differences between various workflows - https://www.youtube.com/playlist?list=PLbAYXkuqwrX2WLQqR0LUtjT77d4hisvfK