Securing only the logon to the J2EE Engine

[MarcelRabe]

Hi,

I'd like to configure the J2EE Engine in such a way that users that only (basic) authentication is done over SSL, but after auhtentication has succeeded the applications itself should all run in http. Simular to how for instance Yahoo offers a secure login.

I understand it's no problem to configure SSL on the J2EE or to run all in SSL, but I don't know how to confure a mixed mode.

Any ideas?

Marcel

[Former Member]

Hi Marcel,

there is no configuration setting like "enable HTTPS only for logon".

There might be a way if you want to write some custom code. I already implemented a scenario where all anonymous content was http and login and everything after login is https. Therefore you'd have to change the action which is called on login. You can achieve this by modifying the com.sap.portal.runtime.logon.par File. Also you have to modify the logout, to switch back to http after logout.

Switching back to http after successfull login is probably tricky. I think you would have to do some unsupported stuff, like modifying the portal launcher, what I cannot recommend

Hope that helps you!

Martin

[WolfgangJanzen]

What's the rationale behind that inquiry?

Wouldn't it be worth to ensure that the (access-controlled) business data is also protected (by encrypted data transmission)?

Once the https connection is established, the performance impact caused by the encryption (with symmetric key) is not so dramatic - the most "costly" part is the SSL handshake (creation of the symmetric key, validation of the SSL server's certificate, optionally: also validating the SSL client's certificate). So it's not really worth to switch-back to http, afterwards.

Regards, Wolfgang

[MarcelRabe]

Hi Wolfgang,

trust me, you are not the first one (and most likely nott he last one either) to answer my question with that question. Therefore I'll make you a deal, if you can tell me wether it's possible or not, I'll tell you the case behind it. It's actually as simple as it is logic.

To be precise: I only want to run the Basic Authentication module secure.

Cheers

Marcel

[WolfgangJanzen]

>

> trust me, you are not the first one (and most likely not the last one either) to answer my question with that question.

If so many people are questioning your approach, you should think over ...

[Former Member]

if you can tell me wether it's possible or not

Perhaps if you have a (series of) webdispatcher in place to handle session ID's on both ports, or redirect with the session ID in the header to http, then you can do it.

But why? Do you want an intermediary (which is not trusted or trustable) to change something? I think it will become a bottle-neck as well.

I'll tell you the case behind it.

If it is performance, then Wolfgang has already addressed this in the "handshake" comment above.

I think if you do not accept that the use-case of this is not a principally secure design for the client, and present your use-case to show that there is one (a business case)... then you will not attract a usefull answer for that use-case.

My 2 cents,

Julius

PS: Perhaps you have noticed logon problems to SDN recently? And constantly being logged off? Same thing... Some one activated http redirects and the caches told them to &%£?"-off...

[Former Member]

To switch back to HTTP after login, the easiest thing I can think of, is to implement a login module which will be added to the login stack at the last place after the CreateTicketLoginModule which does nothing else than a redirect to a HTTP-target.

[Former Member]

If someone is sniffing for passwords, then I don't think that session ID's would be an obsticle for them either.

I thought the idea was to protect the client?

Cheers,

Julius

[MarcelRabe]

HI Markus,

thanks, That sounds both simple as well as plausible. I'll give that a try.

@ Julius. Nope, the idea was only to protect username / password combination. The rest of the data is not sensitive. Thanks though.

Marcel

[Former Member]

Out of curiosity, do you want to change the user context on the server side after the initial login - to be able to dodge some load balancing or WP swaps?

Cheers,

Julius

[MarcelRabe]

Hi Julius,

no, the user context should remain the same and using the same infrastructure. You see, the "challenge" I'm facing is that for approximate 15000 users the logon is done via SPNego and the security officer in charge of our corporate LDAP is comfortable with using Kerberos tickets over HTTP for those users to protect their uid/pwd combination.

HOwever, for about 100 users SPNego is not possible and only Basic Authentication remains (other mechanisms are not possible). To protect their LADP username / password, the communication must be encrypted somehow. A simple solution to me would have been to escape out to SSL and back to normal HTTP during logon. Because to me it seems like an overkill to run the entire portal and all the collaboration rooms in SSL. I understand that this is a proper possibility, but it's not really what I'm looking for. The loss of performance might me debatable, but we've seen it happen especially over low bandwith connections.

Cheers

Marcel

[tim_alsop]

Marcel,

I would be interested to hear why the 100 users are not able to use spnego to logon ? Is it because they are using non domain member workstations, or is there another reason ? I have managed to solve similar scenarios for customers who have special cases for subset of users, and I think if you can give me the details I can give you what you need...

Thanks,

Tim

[MarcelRabe]

Hi TIm,

the users are domain users, but they access the portal through pre-logged-in (anonymous domain members) systems.

rgds

Marcel

[tim_alsop]

Marcel,

My understanding is that you want to find another secure way for the 100 users to logon to your SAP system (portal ?) since spnego cannot be used for these 100 users. I therefore need to understand what you mean by "pre-logged-in (anonymous domain members) systems" - Can you give me more details on this ?

Regards,

Tim

[Former Member]

Now had you mentioned the word "kiosk" earlier...

So you have 100 users who have an AD domain account, but not a PC of their own? However there is a publicly accessible PC for them within the physical intranet?

I have looked into this before as well during an evaluation for a customer, but disabling SSL was not a requirement.

Tim is being humble, his company sells such a solution. I have implemented it once and it works fine.

There are also other 3rd party solutions and even some tricks, but I suspect that latency is a more likely cause of your observed problems than bandwidth.

Have you tested it for network latency? Disabling SSL will not help you much in that case, except a bit for the first hand-shake.

If you have access to a network lab or tools, please test that before offering security as the sacraficial lamb...

Cheers,

Julius

[MarcelRabe]

Hi Tim & Julius

for the most part they are windows based terminals, some domain memebers, some not and they are already logged in. Users can only access a few URL's and systems from there. Much like wat Julius describes. He's referring to something you're selling, can you eleborate?

So far we've just noticed a major performance loss when the portal and all it's content runs in SSL. Mind you, a lot of these locations user very low bandwith connections, so it could also be lantency, but this strikes me as odd as I would expect the same drop from normal HTTP. We are looking into solutions such as AccAD but I thought that just encrypting the logon process would be a nice and simple solution. We might do this anyway, but with third party software and passing authentication through.

Cheers

Marcel

[tim_alsop]

>

> Hi Tim & Julius
> 
> for the most part they are windows based terminals, some domain memebers, some not and they are already logged in. Users can only access a few URL's and systems from there. Much like wat Julius describes. He's referring to something you're selling, can you eleborate?
yes, but not on sdn since it is not appropriate to discuss these details on this forum.
> 
> So far we've just noticed a major performance loss when the portal and all it's content runs in SSL. Mind you, a lot of these locations user very low bandwith connections, so it could also be lantency, but this strikes me as odd as I would expect the same drop from normal HTTP. We are looking into solutions such as AccAD but I thought that just encrypting the logon process would be a nice and simple solution. We might do this anyway, but with third party software and passing authentication through.
> 
> Cheers
> Marcel