Cics Liberty Profile Security without entry in web.xml

Whilst this requirement is valid, based on our current plans and priorities, it is not likely that this could be implemented in the next 12 months, or in the next CICS TS release. Correspondingly this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

We have a big webservice app which should go to production very soon.

Unfortunately we have a problem of "how should security be" at wuestenrot.

This means we have not jet decided which security we want have. As a result of this the app will run without security till this is decided. :(

For me I still see the need to secure the hole app server side and not in the application. This might be "state of the art" in java, but in my opinion at the moment when you run java in cics it has to be protected in a different way.

A possible solution for this could be that if you set a flag in the server.xml there would be no need anymore to include the security context in the application. Cics than could say every app is secure in this way. This would be just a shift of the definition from the application to the server.

But we can discuss this topic at the CAF this year what I would prefer to also hear the opinion of others.

regards Peter

Peter, please do you have any news regarding this RFE. Have you tried it on 5.2 ?

I am sorry, I was not clear enough in the first post. what we really would like to have is that it is possible for us to set up the complete security in the server.xml. If a developer now makes his own security context in the application this should be ignored and allways the one in the server.xml used.

This is what I first wanted.

Coming now to your post. As I know from our tests from Cics 5.1 the Security-constraints from the application must fit the context in the server.

We will set up 5.2 Security in about one to two months, so I don't know if I understand you correctly. You mean I have a context in the sever.xml which represents my security. To use the security the application must take one of the defined ones in the sever.xml. If there is nothing or something wrong defined in the application, the server the application takes the default user for security.

Unfortunately at the moment we have no logon for our cics users, every one is running under the default user :( .... we are working on this.

I think for this RFE it is best to five it on hold. We will try 5.2. It is maybe not exactly what we want, but maybe enough.

I will update the RFE if we when we set up security.

I believe this requirement may be satisfied in CICS TS v5.2. When an application is 'not secured', or more correctly, the application does not contain an explicit security-constraint within its web.xml (deployment descriptor), then all access will be performed under the unauthenticated subject (WSGUEST by default) and this in turn maps to the CICS default user for CICS resources. Correct restriction of the WAS unauthenticated subject and the CICS default userids can prevent unauthorised access to the Application.

Please let us know if this resolves the problem. Thanks.