Kerberos SSO with Password Double-Verification

[Former Member]

All,

I would like to know if anyone has ever set up Portal to have Kerberos authentication with Password based verification?

Thanks in advance,

David

[tim_alsop]

David,

Can you be more specific ? Are you looking to provide authentication to the portal, so a user enters their Kerberos credentials (e.g. principal name and password) into a browser login form, instead of using Kerberos for Integrated Windows Authentication ?

Thanks,

Tim

[Former Member]

Thanks Tim,

The idea is that the Kerberos authentication will provide the user ID (and cannot be changed) but the password will need to be re-entered.

Password re-authentication could be for specific iviews only but the overriding requirement is that the username must be the same.

Username / password are the same as Windows due to AD / LDAP integration (which works very well).

Thanks in advance,

David

[tim_alsop]

David,

I am aware of ways to make a browser form appear instead of just authenticating the user, but when this happens there is nothing stopping the user entering a different account (e.g. principal name) to the account they are logged on to at workstation.

If I understand correctly, your idea woudl be implemented by using Integrated Windows Auth (e.g. SPNEGO) to authenticate the user logged on at workstation, but then show a screen in browser to allow the same user to re-enter their account password (and not be able to change their user account name). I have never seen this implemented yet, and I would be very very surprised if you were to find an existing product/solution available that does exactly this.

If you want this, the company I work for can develop this functionality for you. Personally, I think it is a good idea and could be useful for many SAP customers.

Thanks,

Tim

[Former Member]

Sounds as if you are actually looking for a second authentication after the SSO, or an "electronic signature" with AD password before an iview is successfully called from the portal?

Cheers,

Julius

[Former Member]

That sounds about right

Kerberos > Username

Manually entered password.

Is it possible? If so, any ideas how?

Thanks all so far,

David

[tim_alsop]

David,

Yes, it is possible. It can be done as described below:

1. Take the source code for an SSO login module.

2. Change source so that a new parameter is accepted when this login module is configured in an auth stack. The new parameter could be something like verify-password-after-auth= and will have value true or false. If true, a logon form will be displayed allowing user to enter their password, and login module will only succeed if the password entered is correct. The login module will need to send an as-req to KDC (e.g. Active Directory) for this password verification.

Thanks,

Tim

[Former Member]

How would a login module handle this requirement? (from above)

> Password re-authentication could be for specific iviews only but the overriding requirement is that the username must be the same.

I don't think it would be scalable to list and maintain the iviews in the login module code...

I think that a "confirmation of intent" is actually being sought here, where for whatever reason a "popup to confirm" is not sufficient.

Another option is to use authorizations in combination with an "RFC stub" without saved logon data which closes the connection again. I tried to do this once before, but it never made it to production. The bugger is that complex transactions are hard to build that way and you cannot take much "baggage" with you to the new memory area, or in ABAP OO it might even be desirable that the memory is "private".

Perhaps this is another potential SSFT_PPPI_SIGN candidate?

Cheers,

Julius

[tim_alsop]

>

> How would a login module handle this requirement? (from above)
> 
> > Password re-authentication could be for specific iviews only but the overriding requirement is that the username must be the same.
> 
> I don't think it would be scalable to list and maintain the iviews in the login module code... 
> 
This is not required. Instead, a login module auth stack is configured and the authschemes.xml file can be modified, then the iview can specify the auth scheme which is requried. This will mean that depending on which iview is used a specific auth stack will be used. The login modules are not changed for this, but login module code would need to be changed to make browser show a login form after SSO auth has completed.
> I think that a "confirmation of intent" is actually being sought here, where for whatever reason a "popup to confirm" is not sufficient.
It's more of a confirmation of identity, since SSO is nice, but it means that there is a chance that one user logged onto computer, walked away and is replaced by another user. having this re-authentication is a way to check that the user is still the same user who logged onto the computer.
> 
> Another option is to use authorizations in combination with an "RFC stub" without saved logon data which closes the connection again. I tried to do this once before, but it never made it to production. The bugger is that complex transactions are hard to build that way and you cannot take much "baggage" with you to the new memory area, or in ABAP OO it might even be desirable that the memory is "private".
> 
How can an rfc help, when this is referring to portal logon ?
> Perhaps this is another potential SSFT_PPPI_SIGN candidate? 
Yes, the scenario is similar.
> 
> Cheers,
> Julius

[Former Member]

It sounds as if it is wanted selectively.

> How can an rfc help, when this is referring to portal logon ?

iViews were mentioned, for which selective re-authentication would be required.

Lets wait for more infos...

Cheers,

Julius

[Former Member]

Thank you all for the valuable inputs,

It would be for reauthentication for when a user steps away from the computer. This is to provide additional security for the reasons you mention. The use of authschemes would be for the different iViews would be the desired intention (for scalability).

Tim - your summary seems to be correct - although I'm surprised this has never been done before (particularly for ESS/MSS portal usages).

[tim_alsop]

>

> Tim - your summary seems to be correct - although I'm surprised this has never been done before (particularly for ESS/MSS portal usages).

In my experience, most companies that want/need this kind of feature, are happy to allow their users to enter their AD account name in the browser login form each time they are asked, and not force the account name to be same as the account used to logon at workstation (as it would be if full SSO was used). I think the theory is that the user only knows one account name and password, and since they know their account name they used when they logged onto windows, they can enter the same account name when prompted in the browser. The difference with your requirement is that you want to only allow the user at workstation to enter their password.

In cases where a user logs onto a workstation using one AD account and then wants to logon to SAP using a different AD account name, the browser form Kerberos login module approach which is widely used today, is more suited. Your requirement is differnet because it links the account name used to logon to workstation to the account name used to logon to SAP.

Thanks,

Tim

[tim_alsop]

David,

One of our engineers looked into this requirement and told me that if we changed our product to work the way you wanted, the login form shown to user would still show both userid and password fields, even though the userid field is not required and only password is required since userid is determined based on user logged on at workstation.

The reason for the login form showing userid field is that it is not possible to programatically change the SAP login page to disable userid field, or force userid field to show a particular user and not allow it to be changed.

Thanks,

Tim

[Former Member]

Thanks Tim,

Surely if the username field is still presented, surely I could do this:

1. Kerberos for the main portal (Authscheme "Kerberos" Level 10)

2. Username + Password for the restricted portal (Authscheme "Password" Level 20)

Using the module stacks below

Kerberos:

EvaluateTicket

KerberosAuthentication

BasicPasswordAuthentication (for failover)

CreateTicket

Password:

EvaluateTicket

BasicPasswordAuthentication

CreateTicket

(Proper names not used because I'm not at the SAP system at present).

However, with this attempt, when I go into the secure area it doesn't prompt me - yet if I remove the KerberosAuthentication it works (i.e. passwords in both). What is the reason for this? And would the custom software work differently from this?

Thnaks,

David

[tim_alsop]

David,

I beleive you would need to remove the EvaluateTicketLoginModule from the start of the "Password" auth stack, otherwise the SSO2 ticket sent as a cookie by browser will be used to authenticate the user instead of them getting authenticated with password.

I appreciate that you have not used the exact/correct names, but I was thinking you would need two login modules, as explained below:

1. SPNEGOLoginModule - this login module would use spnego and gss-api to acheive Integrated Windows Authentication. e.g. authenticate user at workstatioin without asking user for anything, just using the Kerberos credentials already available on workstation from when they logged onto the AD domain.

2. KerberosLoginModule - this login module would show a login page in browser and allow user to enter their AD account name and domain, or just account name (and then default domain would be used).

Assuming above, I think you can configure the default ticket stack to use:

EvaluateTicketLoginModule

SPNEGOLoginModule

CreateTIcketLoginModule

KerberosLoginModule (as fallback in case IWA is not possible for some reason)

CreateTIcketLoginModule

BasicPasswordLoginModule (as fallback in case userid and password entered are not valid on domain - they might be valid userid and password in SAP user store instead)

CreateTicketLoginModule

Then for your secure area where you need user to re-authenticate you could use:

SPNEGOLoginModule (used to determine principal name of user at workstation, and store in sharedState)

KerberosLoginMoudule (configured with a parameter to read principal name from sharedState and only use this principal when asking user for their password)

CreateTicketLoginModule

Notice that I have not included an EvaluateTicketLoginModule at start of the secure area auth stack. This is so that the login page is shown even if an SSO2 ticket is already found.

In summary - I beleive the above will do what you need. it does not use auth scheme levels, since I have never been able to make these work the way I understand they are supposed to work - either because of a bug or becuase I am not clear how they work

I hope this helps you understand my proposal better ?

Thanks,

Tim

[Former Member]

Thanks Tim,

I'm comfortable with your proposal - but at the moment I am trying to prove that the current Password module won't pick up the username.

I've followed your advice but still remain with a blank page (removal of the SPNego works fine - with or without those login modules...).

This is the end of the HTML page which is where I would expect the logon screen to be:

<!-- EPCF: Component my.new.logon.certlogon, apdgngjfeijmpompfmpjgpccbdgbfafb -->

<!-- EPCF: Component my.new.logon.default, aoaaghcacmofghehjpaedfccbdgbfafc -->

<!-- component context:my.new.logon.default-->

<!-- class: com.sapportals.portal.ume.component.logon.SAPMLogonComponent-->

</body></html>

My guess is that it gives up but I don't know why...! No errors anywhere, nothing in the logs..

Thanks,

David

[tim_alsop]

David,

The signon screen is displayed by SAP and not by the login module. The login module then gets passed the userid+password entered by user in the signon screen.

When a login module exits, it can store info in the sharedState storage and this info can be read by another login module later in the stack. This is the approach we have used for our login modules to give you the functionality you need. The KerberosLoginModule authenticates the user and then compares the authenticated principal name (not necessarily exactly same as name entered by user due to canonicalization and realm referral features in AD) with the principal name in sharedState - if they are the same then the login module exits with success, otherwise it fails which means the user gets shown an authentication failed error and is expected to enter different userid+password into same login screen.

I would be surprised if your login modules have above functionality,unless you have coded them yourself in the way I have described.

Thanks,

Tim

Edited by: Tim Alsop on Jun 24, 2009 7:42 PM

[tim_alsop]

David,

Previously I said that EvaluateTicketLoginModule cannot be used at start of the auth stack. It just occured to me that this is wrong. If this is not used then after the user has re-authenticated, every page access will also require re-authentication ... Instead, I think we need to use authscheme priority (as you already suggested), but in past I was not able to make this work. We are doing some testing today to confirm the approach suggested will work and I will then update this thread with our findings.

Thanks,

Tim

[Former Member]

Thanks Tim, I did wonder about that.

At the moment I'm trying to demonstrate the disadvantage of the standard objects (i.e. it can be logged into by anyone, not automatic, may be confusing etc).

I can see that the code is working but the BasicPasswordLogin module is "authenticating" the user correctly when they use the password method for both the lower auth scheme and the higher priority one. However, as soon as Kerberos is checked in the Lower priority module the higher authority cannot show the log in screen - and this is concerning.

Thanks!

David

Edited by: David Apthorpe on Jun 25, 2009 10:56 AM

[tim_alsop]

In fact, we have tested and it works for us.

I am able to logon to portal using SPNEGO authentication, and then open an iView which has been changed to use a different auth scheme. I then see a SAP signon screen where I have to enter the account and password used to loogn at workstation. When I have entered correct account and password the iView is shown. I am able to use the iView without it needing to re-authenticate me, but if I open another iView which uses the same auth scheme I get asked to authenticate again. This is because I am not using EvaluateTicketLoginModule.

I don't know why it doesn't work for you, but it does for me.

Perhaps you can show me what you have in your authschemes.xml ?

I can setup a web meeting where I can show you what we have done to make this work. If you are interested, please get in contact with me.

Regards,

Tim

[tim_alsop]

>

> I can see that the code is working but the BasicPasswordLogin module is "authenticating" the user correctly when they use the password method for both the lower auth scheme and the higher priority one.  However, as soon as Kerberos is checked in the Lower priority module the higher authority cannot show the log in screen - and this is concerning.

In SAP Help at http://help.sap.com/saphelp_nw04/helpdata/en/d3/1dd4516c518645a59e5cff2628a5c1/content.htm I found the following:

The frontend target defines which iView is to be launched when a useru2019s session does not satisfy the required authentication scheme. Whereas the login module defines how the user is authenticated, the frontend target defines the user interaction that needs to take place to gather the required information.

The above text suggests that the iView (e.g. the login page) is only shown if the users session does not satisfy the required authentication scheme. I understnad this to mean that the priority in the sso2 ticket is checked with the priority required for the iView and if required the SignOn screen is shown, otherwise it is not shown. So, if you are using sso2 tickets for SSO purposes and storing session details, then you would only get the SignOn screen the first time you access the iView which has the higher priority configured. After that the SignOn screen will not be shown. Our testing has shown this to be the case, and I am not clear if this is acceptable to you, or not.

[Former Member]

Tim,

Just to say thanks for all your help, currently I'm looking into other things but will be coming back to this topic in the near future...

Thanks,

David

[tim_alsop]

David,

Thanks for the update - I wondered why you were not responding

I will wait to hear from you again in future, either via SDN or outside of SDN.

Cheers,

Tim