I'm working on an interesting project when it comes to the login requirements. It's an application that different types of users can log in to:
- users whose login and other data resides within SAP
- users whose login data resides outside SAP whereas their other data resides within SAP
- users who do not exist at all within SAP
On top of that, people can choose their own userid/password for which a confirmation mail needs to be sent to the user. Until the user follows the link in this mail to activate the userid, he/she cannot log in.
Step by step
The above requirements meant that I was not looking forward to the project one little bit. Then I started thinking of a certain D. Jones who wasn't happy with the sound of his songs. So what he did was to write his songs down, cut the paper in to pieces and then put them back together again in a visual way. So I did the same (except for the visual thing). I wrote it all down, cut everything into pieces and picked out the stuff that was quick and easy to do:
- sending the mail is the easiest part since we already do this. If you don't know how to do this, check Thomas' Sending E-Mail from ABAP - Version 610 and Higher - BCS Interface on the subject. Since I prefer to keep everything within BSP though, I used the method described in this help . It isn't a copy/paste example: you need to make some modifications and also delete superfluous code, but normally everybody should cope. If not, let me know if help is needed.
- users may choose their own userids. Since our SAP userids have a specific format it became clear that standard SAP usertables shouldn't be used, certainly since one obviously doesn't want to provide a SAP userid for non personnel.
- users with data in SAP should provide their userid/password in order to check whether they are allowed to view the data. It's generally not a good idea to allow user X to view the data of user Y. However this means that a user should provide two userids/passwords: one for the new application and one for reading the existing data. That's a bit of overkill and an annoyance for the user, so it was decided that the userid should be the same for both/all apps. The system should recognize the type of user in order to check authorisation. Should, I say, but since there is always a (slight) chance that inexistent users choose a userid that looks similar to or even the same as an existing user, the user needs to specify their type of user.
Authentication
So far so good. The only problem that remains is the authentication of existing users. The user type should determine the authentication method:
- LDAP: piece of cake, check Craig's BSP / HowTo: Fun with LDAP and BSP's if you are in any doubt.
- SAP itself is a bit more difficult, certainly when you're not really logged in and want to do it in a safe way. Our system guys promised me a FM that would do the trick safely.
- Somewhere else, wherever that may be
The latter is a tricky one. At this stage of the project it wasn't really required, but I wanted to avoid the risk of getting stuck because of this. I also wanted to avoid having to use X different mechanisms which would make things less maintainable. So I was looking for a general solution that could cover the unknown. Rescue came with the revelation that all the users already appear to have access to web applications. All the users used basic HTTP authentication. Isn't that great? That makes life a lot easier.
Browsing around
The solution was 90% covered in the code mentioned in my article . I only needed to add authentication coding. My first reflex was to provide the credential info in the URL (http(s)://userid:password@someurl), but of course that's far from safe, so I didn't even bother to check the feasibility or to modify the code in such way. So it needed to be done in another manner.
At first I only found something to authenticate against proxy servers. Since proxy servers (should) use the same authentication methods, this will do fine:
call method client->authenticate
exporting
username = user
password = passwd.
Voila, that's it. Nothing to it, is there? Then you can add additional goodies:
client->propertytype_logon_popup = client->co_disabled.
Will avoid that you get a login popup when you are working solely in ABAP and the credentials aren't correct.
client->propertytype_accept_cookie = client->co_enabled.
Will avoid problems when a server wants to set cookies.
OK got that, but how do I check if the credentials are fine? Since it's HTTP(s) authentication, you get the typical HTTP return codes:
200 : Everything is OK
401 : Unauthorised
For the sake of completeness, here's the full code of the FM. Check my earlier mentioned article for further details on the rest of the code.
Take a look too at my eddy.declercq/blog/2005/06/14/it146s-a-matter-of-trust on the troubles you might encounter when you try to retrieve URLs from (and thus try to authenticate against) HTTPS servers.
Conclusion
It's maybe not the most state of the art solution to our problem, but it's certainly fool proof. An additional advantage is that you don't get into trouble when something changes on the back end. For example I'm thinking of switching from SAP users to LDAP users, in which was the front end solution will still work.
This FM can also used for retrieving content as Craig showed at SDN Meets Labs Walldorf and his SDN Meets Labs: Integrated Web Content.
