Skip to Content

HANA XSA Express - xs-security.json missing in MTAR and redeploying

I am working on a very recent XSA Express system ( SPS 03 Patch 64 ( Build 4.3.64 ) ) building MTA applications.

The different components of the MTA application use an UAA service instance for the user authenciation (as stipulated by SAP). In the root of the project a file 'xs-security.json' is created which defines the different scopes, attributes and role templates that are used within the application.

When the application is initially deployed within a space on HANA Express an UAA service is automatically created.

Initially my security file was empty so the service was created without any issues ( as the actual 'content' of that file was empty). Once I did define auth role templates, I believe I then updated the UAA service at some point via the CLI to use the new security data. ( Or more likely I might have deleted and recreated the service via the CLI ).

Later on when I started redeploying a modified MTAR via XS deploy I then noticed that an error occured and deployment was not possible.

When executing the XS deploy I get an error

'Inconsistent xs-security.json: Invalid xsappname: Must not be <null>.' which now - finaly after finding this topic - it makes sense to me ... the security descriptor is not included in the build MTAR binary !

In order to get a new version of my MTA deployed - my solution so far has been:

  1. Deleting the existing UAA service
  2. Deploy the new MTAR. Then the UAA service was created again with no security info.
  3. Then one should think that you could simply update the existing, new service with an uploaded xs-security.json file ( xs update-service yourUAA -c xs-security.json )... Nope ... does not work. Update error that the mentioned xsappname does not match the newly service name - yourUAA <> yourUAA!i1 ... The '!i1' suffix gets added by SAP based upon the spaces you deploy in .. but somehow it can't understand I am updating the same service ... "(Operation failed due to unexpected server error) with error message: 'description: Error updating application yourUAA!i4 (Cannot change AppId with update.)"
  4. Delete the UAA service again (!)
  5. Create the UAA service again referencing the security file ( xs create-service xsuaa space yourUAA -c xs-security.json ). Now the security file is taken into account.
  6. Rebind all your existing apps/services again with the newly UAA service

A not so pleasant side consequence of the above is that all existing roles lost those assigned role templates ... So one has to redefine roles again ... cumbersome ...

I downloaded the latest CLI MTAR builder and build the archive via the command line ... same problem ... still no file included.

The proposed solution in the other topic ? Manually adding the file to the MTAR archive ..

I have the follwoing setting in my mta.yaml file ...

parameters: config_path: ./xs-security.json

I tried several locations in the MTAR file - in the root folder, in the folder META-INF - nothing works .. always the same error ... (sigh) ...

So there seem to be 2 issues:

  1. The bulding of an MTAR file does not include the xs-security.json file
  2. Updating the UAA service via the cli does not work as it compares the appname wrongly

I hope these issues are s getting fixed SOON as this is really frustrating to work properly with MTA...

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

3 Answers

  • Best Answer
    Jul 02 at 12:56 PM

    2nd try. I typed an entire answer and this it got wiped out because I made a textual reference to an SAP domain - my github project. Stupid...

    So first the XSUAA instance can not be updated when you change the xs-security.json. This is a know limitation. You must delete and recreate it. Not nice, but its simply a technical limitation due the complexity of how the scopes and role collections are generated from the xs-security.json.

    On the other item, this is an older problem that has been fixed but perhaps not available in HANA Express since it doesn't have SPS 04 yet. We did work around this in openSAP course by embedding the entire xs-security.json in the mta.yaml. However we removed this in the newer version of the course because this bug was fixed and we could go back to using the xs-security.json file.

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Thomas,

      Thanks for taking the time for answering ... much appreciated !

      I am though a bit confused by your response ...

      So adding the security content in the mta.yaml file solves the issue of the missing security file in the build ( as I understand it ) but ... does it also solve then the updating of the XSUAA instance ? Or do we still have to delete the instance first before being able to deploy ? As deleting the instance alters the roles ( basically removes all the related scopes ) ... and that's a real pain ...

      I hope your above solution solves the deployment issue so we don't have to delete the XSUAA instance ... in that way I guess it only becomes a problem if one needs to change the scopes ... not ideal but less prone to happen if the security is thought out first thoroughly ...



  • Jul 02 at 09:03 AM

    Bump .... any feedback ? This is really blocking serious development / deployment efforts ...

    Thomas Jung Lucia Subatin

    Add comment
    10|10000 characters needed characters exceeded

  • Jul 02 at 01:13 PM

    >So adding the security content in the mta.yaml file solves the issue of the missing security file in the build ( as I understand it ) but ... does it also solve then the updating of the XSUAA instance ?

    It only solves the problem of the missing xs-security.json in the MTAR. Nothing changes the fact that XSUAA simply doesn't support updating an existing instance. That is just a known technical limitation that we must live with.

    Add comment
    10|10000 characters needed characters exceeded

    • Ok thanks for the feedback Thomas ...

      I was thinking about scripting then the dev ops pipeline for incorporating the deletion of the instance first - which can be done - but not sure how we are supposed to perform testing etc when the test account just lost its authorizations ... puzzled ...

      Anyways ... It's kind of a bummer ... hopefully this gets addressed in an upcoming release ..