on 05-21-2019 12:52 PM
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:
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:
I hope these issues are s getting fixed SOON as this is really frustrating to work properly with MTA...
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.
https://github.com/SAP/com.sap.openSAP.hana5.example/blob/hana2_sps03/mta.yaml#L141
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 ...
Thanks,
Steven
>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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 ..
Thanks
Steven
Bump .... any feedback ? This is really blocking serious development / deployment efforts ...
thomas.jung lsubatin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
86 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.