Basic Java security
For those who have ever had to work with basic JEE requirements like web service security and restrict access to business functions in EJB or WDJ applications know that this isn’t easy. It is easy to create the business logic and expose it as a web service. There are wizards in NWDS that guide you. But how do you apply security?
There is no step in the web service creation wizard to guide you adding a minimum authorization level. There is no wizard that lets you define UME actions needed to run a function. Finding out how to do this and putting the several development and configuration steps together is up to you, the developer. This also explains why most Java applications you find in a SAP system are not secured. Try it out: take a custom WDJ or EJB web service and see if you can call it as anonymous user. With some luck, at least the WDJ application requests an authenticated user. But only when the developer explicitly added this during design time. The flag is deactivated by default when creating a new application:
The only thing a user needs to call the application is the URL. Calling a EJB from inside your Java code is not complicated and allows you to circumvent the web service part. How many developers or code reviewers actually check that the interface performs a permission check?
SAP has quite a reputation when it comes to security, as a matter of fact SAP employees can be proud of it in making software enterprise ready. This reputation does not only come from seeing “not authorized to run transaction xyz” all the time, but that you can make SAP pretty secure. Now, why is SAP not supporting developers a little bit more in producing secure Java software?
If a developer gets the task to add web service security, this means: searching for the information on SAP Help or SCN and find a not so easy to understand example. It is not easy to find permission and security best practices on SAP Help for WDJ or EJB. And the developer has to leave the IDE. As this costs time, it’s outsourced to Basis: “add authentication on web service level.” IF it is taken into consideration. Letting the portal handle this is not uncommon, ignoring the fact that the direct URL to call the WDJ application is still accessible. As for using UME permissions to be able to call a business function, this means to implement the action in a new DC, add the action to a role, add the permission check in your code, etc.
This where wizards that guide developers to include security features directly into the application will be more than helpful. As the definitions included during design time are only one part of it, tools that ensure easy configuration of these features during runtime would be even better (DevOps). Instead of letting the developer deploy a secure application that no one can use immediately because of the added security, an automated configuration needs to be executed during deploy time.
Until then, just because you need to log on to the SAP Portal to run a WDJ/EJB application does not mean the application is secured.