1

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.

D Perkins
  • 123
  • 1
  • 10

1 Answers1

0

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

Anton
  • 3,166
  • 1
  • 13
  • 12
  • Thank you for the youtube reference. It was very helpful in understanding the workflows. In the video you mentioned that in the 'Authorization Code' OAuth2 workflow, the user agent didn't have to be a browser. Do you have a reference or example for how to implement the user agent backed by SAML or any of the other identity providers. Basically, I don't understand what AppID endpoints I would call. Or does this only work with a web browser? – D Perkins Jun 05 '19 at 19:19
  • After reading a little more, I think I see how to do this. The user agent would have to communicate directly with the SAML provider and get a grant, and then submit the grant to AppID to get a token. Correct? – D Perkins Jun 05 '19 at 19:33
  • In order to use SAML workflow you must (1) support http redirects, (2) display (or otherwise parse) html login form, (3) populate the above login form with credentials and submit it to the server. Browsers can do all of that, so browser should be used for SAML authentication. Technically - you can write some code that will implement the above login in browserless scenario, but that would require manual html parsing etc. I cannot recommend going this way. Can you describe in detail what exactly you're trying to achieve? – Anton Jun 05 '19 at 22:00