REST Authentication

RE: REST Authentication

Take a look at the introduction article:

https://community.superoffice.com/en/content/content/general/superoffice-restful-api/

And then the documentation:

https://community.superoffice.com/documentation/sdk/SO.NetServer.Web.Services/html/Reference-WebAPI-REST-REST.htm

For Online you need an access token from SuperId.

For on-site installations you need a username + password, or an existing ticket.

You can configure which authentication methods are supported in the web.config file.

Look for the <WebApi> section in web.config

<WebApi>
      <add key="AuthorizeWithUsername" value="true" />
      <add key="AuthorizeWithTicket" value="true" />
      <add key="AuthorizeWithImplicit" value="true" />
      <add key="CORSEnable" value="true" />
      <add key="CORSOrigin" value="https://mail.google.com" />
</WebApi>

RE: REST Authentication

Hi Christian,

I experience the same issue. Do we need to autenticate with a SuperOffice Admin user or a System User?

RE: REST Authentication

Hi, I'm following same issue mentioned from Jon. I have a user which can successfully login on SuperOffice console, but when I call an API, for instance http://theserver/SuperOffice/api/v1/List/WebPanel/Items

I obtain "401 unauthorized"

Can you kindly give me an help?

Our configuration is:

  <section name="WebApi" type="System.Configuration.NameValueSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=fgsdfgsdfgs" />

<WebApi>

      <add key="AuthorizeWithUsername" value="true" />

      <add key="AuthorizeWithTicket" value="true" />

      <add key="AuthorizeWithImplicit" value="true" />

      <add key="CORSEnable" value="true" />

      <add key="CORSOrigin" value="moz-extension://395159fd-2c7a-4343-94a8-7cf2dcf98c3f https://mail.google.com" />

    </WebApi>

Thanks in advance

RE: REST Authentication

Hi,

So I've been testing this myself, and found out that in my case the issue was with having basic authentication enabled on the application (Anonymous and Windows Authentication worked fine).

Will need to test this a bit further, and perhaps get someone with a bit more know-how to explain this issue.

RE: REST Authentication

I experienced the same behaviour. After some research I found out that Basic Authentication was enabled on the application in IIS while it was disabled on the website it self (top level).

After I disabled Basic Authentication on the application I was able to logon with the SuperOffice system user when I connect to the API via the browser. Since the web application does not use Basic Authentication it is the best to disable this on the whole web site and apply this setting on all applications. (top down).

RE: REST Authentication

Same issue here. Using basic auth against /SuperOffice/api/v1/Contact/3 gave a "401 Unauthorized" error. 

Fixed it by following Alexanders tips. Disabled "Basic auth" on the /SuperOffice application, and enabled it on the entire Web Site instead.

RE: REST Authentication

In attempts to mitigate future confusion on this matter, I have appended a new IIS Configuration subsection in the REST article that is more explicit with regards to configuring Basic Authentication.

Best Regards.

RE: REST Authentication

There is a conflict between authentication settings in SuperOffice REST API article and requirements for Single Sign-On. In fact we set authentication to Anonymous and for single sign-on, we need to disable it. Is there a workaround for this? 

RE: REST Authentication

Hi Boyan!

One work around is to have two sites, one for the WebClient/NetServer (daily users) and one just for NetServer Services (REST integrations).

Best regards. 

RE: REST Authentication

Thank you, Tony!

Will test in our development environment. Any other authentication for REST will not work?

Boyan 

RE: REST Authentication

Hi Boyan,

Unfortunately not today. Anonymous Authentication has to be enabled at some point on the web server. 

We do have plans to support at least Windows Authentication in the future.

RE: REST Authentication

You can call the REST API with windows authentication enabled. Obviously we need more documentation around this.

The challenge is getting your client to talk to IIS in such a way that the windows authentication handshake works (windows authentication is requires Kerberos og NTLM tokens, which are requested outside the HTTP conversation with the server).

See Windows Authentication HTTP Request Flow in IIS

These are the headers we get back in the HTTP 401 response to the initial anonymous request:

HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Length: 6055
Content-Type: text/html; charset=utf-8
Date: Tue, 13 Feb 2018 18:57:03 GMT
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
X-Powered-By: ASP.NET

The Windows Authentication module added the "WWW-Authenticate" header, with a value of "Negotiate"

The client browser has received the HTTP 401 with the additional "WWW-Authentication" header indicating the server accepts the "Negotiate" package. The client will prefer Kerberos over NTLM, and at this point will retrieve the user's Kerberos token. The browser then re-sends the initial request, now with the token (KRB_AP_REQ) added to the "Authorization" header:

GET / HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Accept-Encoding: gzip, deflate, peerdist
Accept-Language: en-US, en; q=0.5
Authorization: Negotiate YIIg8gYGKwY[...]hdN7Z6yDNBuU=

Once the server has received the second request containing the encoded Kerberos token, http.sys works with LSA to validate that token. If everything is good, http.sys sets the user context on the request, and IIS picks it up. At this point, the response gets built and the requested resource delivered to the browser:

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 608
Content-Type: text/html
Date: Tue, 13 Feb 2018 18:57:03 GMT
ETag: "b03f2ab9db9d01:0"
Last-Modified: Wed, 08 Jul 2015 16:42:14 GMT
Persistent-Auth: true
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate oYG3MIG0oAMKAQChC[...]k+zK
X-Powered-By: ASP.NET

We can also see an additional "WWW-Authenticate" header - this one is the Kerberos Application Reply (KRB_AP_REP). This is so the client can authenticate if the server is genuine.

RE: REST Authentication

Not sure where to post this, but since you have already referred to your documentation in this thread, I'm attempting here.

Your documentation pages at eg. https://community.superoffice.com/webapi/rest#section/Welcome/ loads *increcibly slowly*. It takes many, many minutes to load, and after having loaded, the page is so large and heavy that it's sluggish when scrolled, and very cumbersome to use.

It would be great if you could fix this ASAP.

RE: REST Authentication

Don't go there.

Go here: https://community.superoffice.com/documentation/sdk/SO.NetServer.Web.Services/html/Reference-Reference.htm

RE: REST Authentication

Hi, has anything changed between 8.3 R04 and 8.4 R04, regarding authentication? 
Before 8.4 following the guide here:

https://community.superoffice.com/en/content/content/general/superoffice-restful-api/

The authentication challange dialog apperad in chrome when accessing  the REST api like this:
http://crm.company.internal/sales/api/v1/contact/2

After upgrade the same setup does not give challange dialog, only error , ERR_INVALID_RESPONSE

If I go with soapui for testing and there use Preemptively Authentication  in stead of global HTTP Setting it does work

So foes the installer of SO-web change anything with in the authentication settings in IIS or is this a change not allowin basic authentication in the browser ?

Edit: A response example, it looks like SO/IIS does not authenticate as it did before when having basic on root site and basic disabled on the sales application/folder, why is that so? :

HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 221
Content-Type: text/html; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
Set-Cookie: SoWtt=; path=/
WWW-Authenticate: Basic realm="SuperOffice username and password, SuperOffice Ticket"
WWW-Authenticate: Negotiate
Server: NetServer/8.4.6915.014
X-Powered-By: NetServer/8.4.6915.014
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 19 Dec 2018 15:07:16 GMT

Use the HTTP <code>Authorization</code> header to log in.<br/>
<p>BASIC scheme with Base64 encoded SuperOffice username:password.</p>
<p>SOTICKET scheme with the SuperOffice ticket (7T:abc123==) without any encoding.</p>

Also:
When using a reverse proxy or LB /(bigIP for example) and doing a reversing from https => http (inside) the Swagger links get wrong protocol it generates on http instead of running https proxied URL that it was called from

RE: REST Authentication

Hi,

Any info about the changed behavior in SO REST API , in 8.4 when trying to access by browser, chrome for example?

See my previous post n this thread.

Best regards
/Anders

RE: REST Authentication

Hi Anders,

Yes, there were changes, perhaps even before that. The article is dated and has not been updated to reflect the changes. 

Unfortuntely there is no official documentation that specifies exactly how your IIS should be configured for your particular scenerio, but as I understand it, it's been "corrected" since that article, and if you want basic authenticate for the site, you need to enable it in IIS. 

I am sorry. I wish there was better official documentation.