PartnerSystemUserService now available as REST endpoint

We are pleased to announce the SystemUser flow now has a RESTful endpoint to exchange a SystemUser token for a SystemUser SOTicket credential.

The prototype to get an SOTicket requires the same parameters as the SOAP endpoint:

  1. A signed representation of your system user token. See how to sign a system token.
  2. An application secret, also referred to as client_secret.
  3. A context identifier, which is the customer tenant ID (Cust12345).
  4. The desired token type, JWT or SAML. We recommend using only JWT as SAML support will eventually fade.
@signed_Token=YOUR_SIGNED_TOKEN
@client_Secret=YOUR_CLIENT_SECRET
@context_Identifier=YOUR_CUSTOMER_ID
@return_Token_Type=JWT|SAML

POST https://sod|qaonline|online.superoffice.com/Login/api/PartnerSystemUser/Authenticate
Content-Type: application/json
Accept: application/json

{
    "SignedSystemToken": "{{signed_Token}}",
    "ApplicationToken": "{{client_secret}}",
    "ContextIdentifier": "{{context_Identifier}}",
    "ReturnTokenType": "{{return_Token_Type}}"
}

This API should only be consumed from a server-side services. Never put sensitive information like your client_secret or private key in a javascript client (or any scripting environment) where it is exposed and vunerable.

Remember to always validate the response to ensure it hasn't been compromised enroute to your application.

Hope this help make it easier to adopt the system user flow for non-SOAP/WCF-friendly applications!

 

 

RE: PartnerSystemUserService now available as REST endpoint

Hi Tony, I'm currently working on a new framework we will use for some new generation SuperOffice apps from InfoBridge. It will be non-WCF indeed by using the AspNet.Security.OAuth.SuperOffice & SuperOffice.WebApi packages, so far that looks promising.

This PartnerSystemUserService was missing so it's a welcome addition, but I'm wondering if some helper methods for this will be included in the SuperOffice.WebApi package? Or is that out of scope? I know it's still pre-release, but to move away from WCF we cannot ignore it.

Von: Carlo Pompen 20. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

The latest SuperOffice.WebApi packages contains a SystemUserClient, see https://github.com/SuperOffice/SuperOffice.WebApi-Samples#system-user

I think that is what you are looking for?

Von: David Hollegien 20. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Thanks David, I did read that before and looks suitable, so there's a bit of confusion what to use when. I should find out by trying it I guess ;)

Von: Carlo Pompen 20. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Hi Tony,

 

The page that explains how to validate the response tells us to use SuperIdTokenHandler which is available in the SuperOffice.Crm.Online.Core NuGet package.

If I reference this package in a .Net Core 3.1 application, I get this warning:

Package 'SuperOffice.Crm.Online.Core 4.0.7275.1215' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v3.1'. This package may not be fully compatible with your project.

If I try to use the SuperIdTokenHandler class, I get this runtime error:

FileNotFoundException: Could not load file or assembly 'System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.

No surprise since System.IdentityModel belongs to .NET Framework.

 

What is the correct way to validate JWT tokens in non-SOAP/WCF-friendly applications?

Von: Véronique Borel 20. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

This is great news! Posting the SOAP-envelope for authenticating the systemuser was a little 'funky' to get starter with, and this new REST-option is much easier to work with for new developers :)

Veronique: I believe the SuperOffice.Crm.Online.Core is made for .net framework, not .net CORE (i remember i was puzzled with the name of the package earlier myself). If you want to create a project on .net core i suggest you take a look at the SuperOffice.WebApi that David posted earlier in this thread. 

Regarding the validation of the returned token, depending on your requirements you could use this to validate the token: 
Override certificate resolver | SuperOffice Community 
The personally prefer this way of doing it. 


//Eivind

Von: Eivind Johan Fasting 20. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Hi Eivind,

It's exactly my point, the SuperOffice.Crm.Online.Core package is not meant for .Net Core, and as you say the WepApi package is better suited for .Net Core, in which case we wouldn't use this new endpoint.

Which means that the page Tony points to to explain how to validate the token is not exactly relevant. The page you point to yourself also references the same package so it's not a solution either.

SuperOffice.Crm.Online.Core is meant for WCF-friendly applications (as it uses WCF services itself). This REST endpoint is meant for non-WCF-friendly applications. How do we validate the token returned by this endpoint without referencing this package?

Von: Véronique Borel 21. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Hi!

I have to admit I did struggle [in my mind] as to whether I should include a link to the Validate token page, and not just mention that you should validate the token without providing a solution how. I think I will just edit the post and do away with the link to that page.

In reference to SuperOffice.Online.Core. R&D has taken steps to convert those libraries to .net standard, and it won't be long before the nuget packages get updated. Balancing resources and priorities is hard.

Let's please take a step back to gain some perspective. Like David pointed out, the SuperOffice.WebApi library (.NET Standard 2.0 - for both .NET Core and .NET Framework) already contains and implements a SystemUserClient that does the fetching and validation for you.  So with that in mind, one could say that the new endpoint is available for non-.NET libraries, or those who wish to code their own SystemUser client.

In reference to how to perform validation, I suppose I could write an article that explains how to perform JWT validation. There are dozens on the interwebs, but even after all this time I still struggle with determining where to draw the teaching line between general application development and SuperOffice APIs development? How far down the rabbit hole should I go? 

On second thought, that's a little narrow as it just addressed JWT validation and not SAML validation. Hmmm... We are advocating people not use SAML anymore, so there is that... I would rather lead you in the right direction, in accordance with our roadmap, rather than provide a means to an end that we do not want to continue to support long-term.

I have contributed to the open-source project AspNet.Security.OAuth.Providers  project does demonstrate how to perform JWT validation, but perhaps a more explicit walk-through would be more appropriate. I'll add that to the backlog.

I do just want to help make it easier to work with the API's, so I am sorry for any confusion. 

Von: Tony Yates 21. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Tony: Great news that the nuget packages will be upgraded to support .net standard :)

Veronique: Validating the token is something you can do without any of the nuget-packages from SuperOffice. 
I actually tested this earlier today to verify it works. Here is how i ended up validating the token

 private static TokenValidation ValidateJwtToken(AuthResponse authResponse, string publicKeyPath)
        {
            var tokenHandler = new JwtSecurityTokenHandler();

            X509Certificate2 cert = new X509Certificate2(publicKeyPath);
            SecurityKey key = new X509SecurityKey(cert);

            TokenValidation tokenValidation = new TokenValidation();

            try
            {
                tokenHandler.ValidateToken(authResponse.Token, new TokenValidationParameters
                {
                    IssuerSigningKey = key,
                    ValidateIssuer = false,
                    ValidateAudience = false
                }, out SecurityToken validatedToken);

                tokenValidation.JwtSecurityToken = (JwtSecurityToken)validatedToken;
            }
            catch (Exception ex)
            {
                tokenValidation.IsSuccessful = false;
                tokenValidation.ErrorMessage = ex.Message;
            }
            return tokenValidation;
        }

Note that i have created my own models for AuthResponse (which is what i get back from the REST endpoint this thread is all about) and TokenValidation (which i use elsewhere for logging if this validation should fail). 

I THINK i only use System.IdentityModel.Tokens.Jwt and Microsoft.IdentityModel.Tokens. 
An alternative is the code Christian posted in this thread: 
Topic | SuperOffice Community 

We are moving a little off track of this thread so if you need more examples i sugges you make a thread and more people can give their inputs on it :) 

Hope it helps, have a SUPER day!

//Eivind




Von: Eivind Johan Fasting 21. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Thank you both!

With Tony's answer we have an example how to validate the token the OIDC way, which doesn't require installing public certificates, while Eivind's example is useful for apps that don't use OIDC.

It's definitely helpful to have both these scenarios covered here :)

Von: Véronique Borel 22. Apr 2021

RE: PartnerSystemUserService now available as REST endpoint

Hi Tony, the signed systemusertoken, which includes a timestamp, does it have a timelimit on how long it is usable?

Von: Frode Lillerud 7. Mai 2021