28 Replies Latest reply on Aug 12, 2014 11:07 AM by nilsheuer

    401 Unauthorized on .NET calls to v3 API

    dbgilbert Novice

      I'm trying to work out how to communicate with Jive's v3 API with .NET. My company uses SSO with Jive, and when opening the request URL in a browser I do receive the information desired, but when I make the request as shown below via .NET, I receive a 401 Unauthorized error.


                  HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://myCompany/jiveon.com/api/core/v3/people");

                  request.Method = "GET";

                  request.Accept = "application/json";

                  request.Credentials = new NetworkCredential(username, password);

                  request.UseDefaultCredentials = true;

                  request.PreAuthenticate = true;

                  request.Headers[HttpRequestHeader.Authorization] = "Basic " + Convert.ToBase64String(Encoding.ASCII.GetBytes(username + ":" + password));


      I've tried every variation of this I can think of and I always received 401 Unauthorized. The only clue I have to what's wrong is that when I tried to open the URL in Chrome's Incognito mode (preventing the browser from identifying itself automatically with my work credentials) but provide the credentials like this: "https://username:password@myCompany/jiveon.com/api/core/v3" I receive the same unauthorized error.


      Am I misunderstanding some aspect of authorization/authentication for the API? Does SSO not translate to Basic Auth the way I think it does?

        • Re: 401 Unauthorized on .NET calls to v3 API

          I'd be surprised if Jive allowed you to authenticate using basic auth.  Our company does federated auth with Jive hosted using SAML and ADFS so making programmatic connections is more complicated than simply setting the username and password on the web request.  I think OAuth is an option too but I might be wrong.  When you say your company does SSO, what technologies are involved?  What's the user sign-in experience like when using the browser?

          • Re: 401 Unauthorized on .NET calls to v3 API
            jrlarson Advanced

            It is not possible to authenticate against the REST API as a federated user. The password stored in the Jive DB is some randomized value that has no relation to the password stored in the IDP.


            The API is not SSO enabled.


            Your best bet is to create a non-federated 'service acount' with full access admin rights, authenticate against the API with that service account, then use the run-as headers to execute your API calls as a specific user.


            Core V3 API - Run-As Feature & Signed Add-Ons

            1 person found this helpful
              • Re: 401 Unauthorized on .NET calls to v3 API
                dbgilbert Novice

                The "service account" strategy has been successful, and I can make API calls with its credentials. Thanks for the suggestion.


                We're having a little trouble setting up Run-As, though. When I go to Admin Console->System->Management I see nothing but the audit log viewer. I assume I'm missing privileges or something; I should be able to see/modify System Properties, right?

              • Re: 401 Unauthorized on .NET calls to v3 API

                As long as you can simulate the initial authentication process (again, curious how your company has SSO set up), you can hit the REST API as a federated user.  As I mentioned before, our company uses ADFS which works internally with Windows integrated authentication.  Setting the HttpWebRequest.UseDefaultCredentials property to true tells the HttpWebRequest to use my Windows credentials.  Since our SSO process is a series of redirects between Jive and ADFS, we also set the HttpWebRequest.AllowAutoRedirect property to true as well so the request object will follow HTTP 302 redirects.  The key is sharing a CookieContainer object between multiple HttpWebRequest objects by creating a CookieContainer and assigning it to the HttpWebRequest.CookieContainer property.  That way, each subsequent request will include the Jive session cookies.  Once you've completed the authentication process once, you can issue as many requests against the API as you want for the life of the Jive session without having to reauthenticate.

                • Re: 401 Unauthorized on .NET calls to v3 API

                  To be clear, John Larson is correct in stating that you can't perform the necessary authentication steps while hitting the REST API URLs.  You have to perform authentication against a non REST API URL (we use the root of the site) and then once you have the Jive session cookies, you can hit the REST API.

                    • Re: 401 Unauthorized on .NET calls to v3 API
                      whoiskevin Expert

                      In previous versions I solved this by adding an additional authentication filter via a plugin.  That filter would examine the rest request for the SSO cookie.  If found it would attempt to verify against the SSO endpoint and then cache the result.  Since there was no session this accomplished having repeated calls without sessions and without every call going back to the SSO source.


                      This solution depends on a few things. Of course the plugin but also that the calls from the application include the necessary corporate SSO tokens, cookies, or whatever.  But I found that it was low overhead and more appropriate in a corporate setting where the integration is expected and there is no end user approval process required.


                      I'm still looking at Jive 7 and the new API where some of this can be solved with addons if I can get them fully functional while air gapped (no cloud).

                    • Re: 401 Unauthorized on .NET calls to v3 API

                      Is there a reason why you cannot use OAuth to authenticate with the REST API. I've successfully used this approach to work around the SSO/federated user restriction.


                      Happy to share my code if that is an option for you. It does require user interaction for the initial setup, so it might not be 100% perfect for server to server integrations, but it works like a charm once set up.