Single Sign-On for Java with SPNego
“I changed my password everywhere to ‘incorrect.’ That way when I forget it, it always reminds me, ‘Your password is incorrect.'”
Gartner estimates that password reset requests account for 20% to 50% of a typical Help Desk’s call volume, while Forrester Research estimates each call costs about $70 in Help Desk labor (seems high to me, but who am I to argue with the experts?). It doesn’t take complex calculus to see that this can add up to a significant cost driver for IT organizations.
“Sorry, but your password must contain an uppercase letter, a number, a haiku, a gang sign, a hieroglyph, and the blood of a virgin.”
A number of tools are available to help reduce this burden, such as automated password reset self-services, password managers, or the subject of today’s blog, Single Sign-On (sometimes also known as Integrated Authentication) using SPNego.
Do I Need to License SAP NetWeaver Single-Sign (NWSSO)?
If you are planning to implement an SSO scenario involving your ABAP system, then yes, you will need to implement NWSSO as described in the many blogs and documents over in the SAP Single Sign-On space. This is a versatile tool that can help you implement SSO for SAPGUI, for WebGUI, and for the various web-based applications you might run on an ABAP system (such as SRM, for instance).
NWSSO can also provide your SSO solution for your Java-based systems, such as Enterprise Portal, but it’s not absolutely necessary for this scenario.
That’s where this blog comes in. I’m going to describe for you how to configure Single Sign-On to your Enterprise Portal for your Windows domain-based users using only the tools that come with a NetWeaver Java 7.x system and Active Directory (and a typical JRE, such as that supplied by Oracle). No extra product required. The method described should work on AS Java 7.00 from sp23, 7.01 from sp8, and 7.02 from sp6. It will also work on 7.1 and higher versions with some slight adaptation (mainly the use of NetWeaver Administrator instead of Visual Administrator). If you are still working with an AS Java below the above-mentioned support pack levels, then there is an add-on available to enable this functionality (see Note 1457499).
In other words, no, for SSO from Windows domains to Enterprise Portal, you do not need NWSSO.
What is SPNego?
SPNego is Simple and Protected Negotiation Mechanism. It has been around since the days of Microsoft Internet Explorer 5.01 and Internet Information Services 5.0, and today it is supported by Firefox and Chrome as well as IE11. It is a “pseudo” implementation of GSSAPI, or Generic Security Services Application Programming Interface. While it used to depend upon NTLM, an older Microsoft-specific authentication protocol, today it mostly relies upon Kerberos, a standard ticket-based protocol utilized by Windows and UNIX systems alike.
SAP NetWeaver Java can utilize most Kerberos Key Distribution Centers, but in this blog we will focus on what is arguably the most common: Microsoft Active Directory.
What are the Client Browser Requirements?
For the most part, the default setup will work:
- Integrated Windows Authentication must be enabled:
- Tools… Internet Options… Advanced… Security… Enable Integrated Windows Authentication
- This is usually enabled by default.
- Tools… Internet Options… Advanced… Security… Enable Integrated Windows Authentication
- Automatic Logon must be enabled for the Local Intranet Security Zone:
- Tools… Internet Options… Security… Local intranet… Custom level… User Authentication… Automatic logon only in Intranet zone
- This setting is enabled with the Medium-low security level, which is the default level for the Local intranet zone.
- Tools… Internet Options… Security… Local intranet… Custom level… User Authentication… Automatic logon only in Intranet zone
- If you use a proxy server for web browsing, it must be bypassed for local addresses:
- Tools… Internet Options… Connections… LAN settings… Proxy server:
- Either Use a proxy server for your LAN must be UNchecked, or if it is checked, then Bypass proxy server for local addresses must be checked.
- Tools… Internet Options… Connections… LAN settings… Proxy server:
- Your Java system must be included in the Local Intranet security zone:
- Tools… Internet Options… Security… Local intranet… Sites:
- Various options: typically, Automatically detect intranet network is checked, and beneath that the other options as well (Include all local (intranet) sites not listed in other zones, Include all sites that bypass the proxy server, and Include all network paths (UNCs)). Alternatively, or in addition, in Advanced you can specifically add your Java system to the zone, or you can add a range of IP addresses or your local domain (*.domain.com). This is often controlled via Group Policy.
- You can confirm if your Java system is properly showing up in the right zone by right-clicking on the login page and choosing Properties. There you should see Zone: Local intranet | Protected Mode: Off.
- Tools… Internet Options… Security… Local intranet… Sites:
In the address bar enter about:config to see the various configuration settings. Filter them by typing negotiate in the search bar, then modify network.negotiate-auth.delegation-uris to add the URL of your Java system. Do the same for network.negotiate-auth.trusted-uris.
Again, your Java system must be included in the list of sites that bypass your proxy, if used.
Active Directory Service User
If you’re the Basis Administrator, chances are you are not also the Active Directory Administrator. So, you may be thinking to yourself, I’ll never convince them to make changes to Active Directory if this requires something like a schema extension…
Well, fear not! No schema extension or heavy modification of AD is required. Indeed, all you require is a very simple service user account, and the configuration of an SPN, or Service Principal Name, for that service user.
So, the first decision (or negotiation) is to determine the name of the service user. My recommendation is to choose something along the lines of SAPSSO-<SID>, i.e. if your Java System ID is PLQ, then your service user will be SAPSSO-PLQ. However, the naming convention is not a hard rule, unlike the service accounts used for running and managing the SAP system itself, so if your organization’s convention for service accounts requires something different, that is fine.
The service user does not require any special privileges or permissions, but it does require these two account options:
- Password never expires must be CHECKED;
- Use Kerberos DES encryption types for this account must be UNCHECKED.
- Note that older versions of the SPNego implementation in SAP Java actually called for DES to be enabled, but that is no longer true. DES is an older encryption algorithm that is no longer considered secure, and thus it is better to ensure that it is not enabled here.
Service Principal Name
The small bit of extra configuration that must be done for the service user is setup of the Service Principal Name, or SPN. This can be done with Microsoft’s ADSI Edit tool, or via the command-line from any domain member Windows workstation. The SPN must follow the format of:
HTTP/<FQDN of Java host>
In other words, if your Java system is portal.domain.com (highly original, I know), then the SPN is HTTP/portal.domain.com.
To configure the SPN from the command-line, type (or have your AD administrator set):
setspn -a HTTP/<FQDN> <service-user>
In our above example, that would be “setspn -a HTTP/portal.domain.com SAPSSO-PLQ”.
If your portal or Java system has multiple DNS aliases, i.e. it’s known by a “technical” hostname such as “s1x37bz.domain.com” as well as a “friendly” name like “portal.domain.com” then you must set both SPNs against the service user. It’s still just one service user, but the user will have two registered SPNs. Likewise, if your portal system has multiple hosts, for load-balancing purposes for instance, plus a web dispatcher to provide the load balancing, then you must set an SPN against the service user for each host.
Also, even though you are surely using HTTPS and not HTTP to connect to your portal, you will specify HTTP in the SPN.
What’s important here is that each SPN must be uniquely assigned to only a single service user, but each service user may have multiple SPNs.
Check SPN Configuration
This part you can do yourself, even if you are not the AD administrator, so you can confirm that the SPN is correctly setup and unique. From a command-line on your workstation type:
ldifde -r serviceprincipalname=HTTP/<FQDN> -f out.txt
Remember, put in the actual host and domain name, i.e., portal.domain.com in place of <FQDN>. If all goes well, you should see messages something like:
Connecting to “<domain-controller.domain.com>”
Logging in as current user using SSPI
Exporting directory to file out.txt
Searching for entries…
Writing out entries.
1 entries exported
The key here is that 1 entries exported (grammar rules notwithstanding). There can be only one! Now, look in the current folder (wherever you were in command prompt when you ran ldifde) for out.txt and examine the contents. You will see a bunch of information, most of which you can safely ignore. The key lines you are looking for, close to the end, are:
userPrincipalName: SAPSSO-PLQ@domain.com (or whatever the correct service user account name is plus your domain)
etc for however many SPNs you configured for the user (perhaps only one).
Now that you have a service user, you must create a keytab file that contains the encryption key required to decrypt the Kerberos tokens supplied by the browser to the AS Java. The easy way to do this is with the JRE you probabably have installed on your workstation. Any Java 1.6 or higher JRE should do (note, this will definitely not work with JRE 1.4, even though the KTAB utility exists; I tried).
Open a command prompt and navigate to the bin folder of your JRE, i.e. C:\Program Files (x86)\Java\jre1.8.0_65\bin, etc. From there, type the following command:
ktab -a <service-user>@<domain> -k ssokeytab<sid>
So, if your domain is mycompany.com and your service user is SAPSSO-PLQ (because your Java SID is PLQ), then you would type ktab -a SAPSSO-PLQ@mycompany.com -k ssokeytabplq.
You will be asked to enter the password for the service account. Be careful, as ktab does not validate the password with Active Directory; it just uses it to create an encryption key. If you type in the wrong password key, the encryption key won’t work.
Move or copy ssokeytab<sid> to an appropriate location other than your JRE program folder.
In your web browser, logon to your AS Java with the following URL. Make sure your user account has administrative privileges on the Java system.
For example, the URL might be https://portal.mycompany.com:50001/spnego. This launches the SPNego Wizard.
Note, if your system is NetWeaver 7.1 or higher, you can access the wizard from NetWeaver Administrator via the path Configuration -> Security -> Authentication and Single Sign-On and then choose the SPNEGO tab. A few of the steps are different in a very minor way from the below, but it is essentially the same after this and you should be able to follow along with these instructions.
You will see a list of Kerberos Realms configured for access. Assuming this is the first time you’ve used the wizard, there won’t be any.
- Click Add.
You will see a New Realm pop-up. In the Name field enter the name of your realm. Oh, and if you aren’t sure what a realm really is or what the name should be… it’s the same as your Active Directory domain, i.e. mycompany.com. You can enter anything you like in the Description field or just leave it blank. Click OK.
Now your list of realms includes the one you just created, but it’s not yet enabled and it doesn’t have any details.
- With your new realm selected, click Edit.
In the Details of realm section below, there are two tabs, User Mapping and Keys. In the User Mapping tab, select the following:
- User Mapping
- Mapping Mode = Principal only
- Source = Logon ID
One note here: this mode assumes that usernames for your Portal users match their usernames in Active Directory. If you are using AD as an LDAP source for users, that is probably the case. If you are using your ABAP backend as the source for users, you may have some mismatches. At a later time I will follow up with a blog about how you can set up SSO to work for mismatched usernames as well, but for now we are going to assume all usernames match.
Second note: this works just fine if you are using your ABAP system as the user source; using LDAP for your users is not a requirement.
- Now select the Keys tab and click on Add. The Add Keys dialog will pop up.
- Click Browse and browse to the ssokeytab<sid> keytab file you created in the Encryption Keytab step.
- Click Import.
In the Add Keys dialog you should now see one or more keys displayed in a list (probably just one, but if you are enabling other encryption protocols besides RC4, you might see a couple). You’ll also notice that your AD service user is listed in the Principal field. Ensure the Selected checkbox is checked for all keys in the list, and click OK.
- You just need to Enable the realm and Save it.
When you’re done the Status field should show a green light. You’re done with the wizard.
If you are on NetWeaver 7.1 or higher, you can remain in the NetWeaver Administrator for this next step. You just need to click over to the Authentication tab after completing the SPNEGO tab.
If you are on NetWeaver 7.0x, you’ll need to access your server console and start up Visual Administrator.
- Navigate to Cluster -> Server 0 -> Services -> Security Provider.
- Under Runtime -> Policy Configurations -> Components select the ticket component, then click the Edit mode button.
If you see a Login Module called SPNEGOLoginModule (with capital letters just like that), remove it (select and click Remove at the bottom of the screen). That is an out-of-date module. Most likely, however, you won’t see this here.
Most likely you will see three login modules as shown in the screenshot above. You will leave these three and add to them (and potentially make some minor modifications to options).
- At the bottom of the screen, click Add New. In the Available Login Modules popup dialog, scroll down through the list and select SPNegoLoginModule (notice how the capitalization is different from the out-of-date module we talked about above). Click OK.
- Click Add New again and this time select and add CreateTicketLoginModule (yes, I know you have one in there of this name already; you need two of them).
Your stack now should have five login modules:
We need to rearrange their order and adjust their flags, and possibly options.
- Select SPNegoLoginModule and click Modify at the bottom. The Edit Login Module dialog should pop up.
- Change Position to 2 and change Flag to Optional. Click OK.
- Select CreateTicketLoginModule (the one you just added, at the bottom of the list) and Modify.
- Change Position to 3. The Flag should already be Sufficient, but if not, adjust it.
- Under Options, type ume.configuration.active into the Name field, and true into the Value field. Click OK.
You’ll note that your new CreateTicketLoginModule just gained a prefix of com.sap.security.core.server.jaas just like the other one already had.
- Select the other com.sap.security.core.server.jaas.CreateTicketLoginModule (the one that you didn’t just edit, and which should be at the end of the list) and click Modify.
- Change Flag to Required and click OK.
When you are done editing the authentication stack, it should look like this:
Make sure the modules appear in this order, and that their flags are set this way.
Login Modules and Flags
Ok, so that was a neat bit of work, but what does it all mean? What do the login modules do, and how do the flags influence things? And why do we need two CreateTicket login modules?
Login Module Order
The authentication stack represents an order of processing, and the flags represent decisions as to where the processing should go next based upon a pass or fail of the module, much like a workflow decision tree or program logic. When a user attempts to login to the AS Java, the modules are called in the order they appear in the stack.
- Is the user coming to the system from another trusted SAP system, such as another Enterprise Portal, or perhaps from an external portal such as Sharepoint, and did that system pass an SSO2 login ticket with a valid SAP authentication? This is the same scenario you encounter when accessing reports or webdynpros, etc, in your backend system via an iFrame in your Portal, or when you access any other system in your landscape (SRM, perhaps) from your Portal. The Portal passes on your credentials to the next system so you don’t have to keep logging in each time you click a link in the Portal. These are the same SSO2 login tickets you have probably dealt with in the STRUSTSSO2 transaction in your ABAP system.
- If this is the case, then obviously we want the SSO2 login-ticket-based authentication to work silently in background without interrupting the user. Thus, we evaluate to see if there is such a ticket (and that it’s valid) first.
- Assuming the user did not have an SAP-system-generated SSO2 login ticket (meaning this is probably first entry into the Portal), then we look to see if there is a valid Kerberos token indicating the user has already been authenticated by Active Directory. If there is, then we match that token against our Portal user store according to the rules we configured in the SPNego Wizard, and if there’s a match, we accept the token and authenticate the user. No login screen need be presented.
- Once the user has been let in to the Portal, whether by existing SSO2 login ticket or by SPNego/Kerberos token, it is likely he/she will want to use resources from other systems that the Portal is a front end for, such as our ABAP system. Thus, we create an SSO2 login ticket for the user which will be passed on to downstream systems to use in their own EvaluateTicketLoginModule.
- On the other hand, if there was not a valid SSO2 or SPNego ticket, then we want to give our user an opportunity to type in a username and password in the old-fashioned way. That’s what this login module does.
- Again, if our user logged in with username and password instead of a ticket/token, we still want to give him/her an SSO2 login ticket for the downstream systems. Thus, we need this module again.
I know what you’re thinking. Why don’t we just put CreateTicket in only once, at the very end? Well, I think you’ll understand the answer to this when we examine the Flags on the login modules.
We saw four different flags in use:
- If the login module succeeds, authenticate the user and exit processing of the stack here. If it fails, proceed to the next item in the stack. However, the user can still be authenticated by a later module in the stack.
- Whether the login module succeeds or fails, continue processing with the next item in the stack. If successful, the user is at this point authenticated even though we’re still processing, whereas if it fails, the user can still be authenticated by a later module.
- If the login module succeeds, authenticate the user and proceed to the next item in the stack (just like Optional). If it fails, exit processing here, and the user is not authenticated. This is essentially the opposite of Sufficient.
- Whether the login module succeeds or fails, continue processing with the next item in the stack. However, if it failed, there is no further chance to authenticate, regardless. This is similar to Optional except for that last point.
So, our processing flow is as follows:
- EvaluateTicket, Sufficient
- If the user has a valid SSO2 ticket, authenticate the user and exit processing the stack. The user is logged in.
- If the user does not have an SSO2 ticket, proceed to the next item.
- SPNego, Optional
- If the user has a matching Kerberos token, authenticate the user and proceed to the next item.
- If the user does not have a Kerberos token, proceed to the next item.
- CreateTicket, Sufficient
- If the user is already authenticated by the previous module (SPNego), create an SSO2 ticket and exit processing the stack. The user is logged in.
- If the user did not authenticate via SPNego, do not create an SSO2 ticket, and proceed to the next item.
- BasicPassword, Requisite
- If the user enters a valid username and password, authenticate the user and proceed to the next item.
- If the user’s username or password is invalid, exit processing the stack. The user is not logged in (and gets an error and remains on the login screen).
- CreateTicket, Required
- If the user is already authenticated by the previous module (BasicPassword), create an SSO2 ticket and proceed with the next item. This is the last item, however, so the user is logged in.
- If the user is not yet authenticated, they won’t have reached this step. However, if that did happen somehow, no SSO2 ticket would be created, and although processing could in theory proceed to a later step (if there was one), because of the Required flag no further step could authenticate the user. They’re done at this point.
For more details about authentication stack processing, see the SAP Help at Login Module Stacks – User Authentication and Single Sign-On – SAP Library.
Logoff Redirect URL
At this point your Single Sign-On should be working. However, there is one additional configuration item you should attend to if you don’t want to annoy both users and system administrators, and this is the Logoff Redirect URL.
By default (meaning if this parameter is not set), when a user logs out of the AS Java they are sent to the login screen. Normally there is nothing wrong with that, but if SSO is active (and if you’ve been following along, it is now in your system), what do you think happens when the user clicks that Logoff button and is sent to the login page?
That’s right. SSO logs them right back in again. It’s almost like an endless loop. The Logoff button essentially does nothing.
This is very easy to change, but the unfortunate point is that this change, believe it or not, requires a restart of the Java stack. That’s right, everything you’ve done up to now took effect immediately, with no service interruption — you could have turned all this on during business hours, even — but for this last little piece of configuration you’ll need to schedule a brief downtime.
So, let’s get to it. You can do this in either the Config Tool or the Visual Administrator, but you’re already in Visual Administrator, so we’ll do it from there. The key is to make sure you are updating the Global Configuration and not an individual server instance.
Side note: the configuration of the authentication stack in the Security Provider Service replicates to all server instances in the cluster. You don’t need to repeat these changes in each instance. However, the logoff redirect URL is server instance specific unless you make sure to edit the global configuration (or use the Config Tool).
- In Visual Administrator, select Global Configuration -> Server -> Services -> UME Provider.
- If you prefer to use Config Tool instead, the path is cluster-data -> Global server configuration -> services -> com.sap.security.core.ume.service.
- If you are using NetWeaver Administrator, the path is Configuration -> Infrastructure -> Java System Properties -> Services -> User Management Engine.
- Scroll to the property key ume.logoff.redirect.url and select it.
- In the Value field, enter the URL of the website you want to send users to (perhaps a corporate intranet homepage).
- Click Update.
- At the top of the list of properties, click Save Properties (the standard floppy disk icon).
A pop-up dialog will open asking Apply these changes to cluster elements? There will be a list of all the server instances, and by default they will all be checked. Almost certainly this is what you want to do, so click Yes.
Another pop-up will open warning you that Service UME Provider on Server x x_xxxxx is a core service. Restart of Server x x_xxxxx is needed for the properties changes to take effect. Click OK. The pop-up will repeat for each server instance you have, so click OK to all of them until there are no more.
Exit the Visual Administrator and restart the cluster (with SAPMMC).
What if I Need to Login as Different Users for Testing or Administration? (Bypass SSO)
Fear not! A simple addition to the login URL of your Portal will bypass the SPNego module, thus taking you straight to BasicPassword. Simply enter your URL as follows:
That’s it. You’ll go straight to the login page.
- Note 1488409 (New SPNego Implementation) has the latest SPNego Configuration Guide as an attachment. Currently the latest one is dated 2011. There are also some links to further troubleshooting Notes.
- Note 968191 (SPNego: Central Note) has further links to troubleshooting Notes.
Do not be confused by Note 994791 (SPNego Wizard). That Note is for older support pack levels of the AS Java which do not already have the wizard incorporated, and it provides the wizard as a downloadable EAR fileto deploy on your system. You don’t need this unless you are actually using such an old system.
Hi Matt, very nice blog!
How about recommending AES encryption options at the service user account level? Otherwise SSO will rely on RC4 which is considered outdated/insecure. Have a look at Kerberos(SSO): throw RC4 away, adopt AES ! and Security Level of Kerberos / SPNego Algorithms?
Hi Lutz, and thank you for your comments and the links to those discussions. You do raise an important point.
I haven't yet found documentation to indicate at what release and SP levels the AS Java will support AES (I know that Active Directory with Windows 2012 DCs will), so until I know that I hesitate to document the process for others. One of the discussions you linked is talking about BusinessObjects, which is a different beast, and so it's not necessarily a translation across to AS Java. However, you are quite correct that AES is more secure than RC4 (and considerably more so than DES).
The only blogs I was able to find about configuring the SPNego SSO for an AS Java before writing this one still recommended enabling DES, as below the SP levels I mention in this post that was apparently the highest encryption that the "old" SPNego would support. Much of the older documentation floating around on SCN and SMP still advises to do this. So, I'm hopefully at least disabusing people of that notion.
Over the next few weeks and months I will be doing further experimentation with our own servers, both to determine a working method for mismatched AD<->SAP usernames, and to validate that AES encryption can be made to work with NW 7.01 (I don't like to blog about anything I haven't actually done myself in "real life"). Meanwhile, I'm hoping that here I'll have clarified a few misconceptions that may be floating around out there (that I myself had, until I embarked on this project).
Doing so should help with clarifying some of the questions you raised in your discussion thread, i.e. what limitations are imposed when restricting the algorithm to AES, and just how does Kerberos negotiate which algorithm to use. From documentation I've read, Kerberos should negotiate between client and server to identify the highest common supported algorithm, in which case if the server supports DES, RC4, and AES, and the client supports RC4 and AES, then AES should in theory be chosen. However, that will take some testing to validate. If true, and a downlevel AS Java only supports up to RC4, but AES is enabled on the client (via the AD service user), then SSO should still work even though the negotiation will result in RC4 being chosen.
On a side note, although 95% of the workstations in my organization are now running Windows 7 (and only just -- it was about a four-year project to get 20,000 PCs upgraded), I still have a very small handful of XP clients out there. Thankfully I think it's down to numbers I can count on my hands (perhaps just one hand), but there it is.
Once I've confirmed that AES works in my environment, I'll update the blog.
Thanks again, and I look forward to further discussions!
I am really glad that you did a refresh of this subject, because most stuff on this subject is very old indeed.
AES for SPNEGO on AS Java was introduces by note http://service.sap.com/sap/support/notes/1457499 :
AES should be no problem with Windows XP as long as it is SP3 and the AD is 2008 or newer according to this:
Unfortunately I have no XP system left so I am not able to verify.
I would be glad if we could all collect more facts about compatibility and incompatibility of AES and Kerberos/SPNego. My impression currently is that rollout of AES is typically prevented based on rumours. SAP's product management is also adding to this unspecific rumours when questiones instead of communicating facts.
Thanks! That's what I was looking for.
Yes, I suspect the information may be somewhat buried because of a general push of customers toward the separately-licensed NWSSO product. But of course, I would never suspect this of being intentional!
It turns out that AES encryption for Kerberos tokens requires NetWeaver 7.20 or higher (SPNego Kerberos Authentication - SAP Netweaver Application Server Java - SCN Wiki) (Note 2218506). It is possible to enable AES128 and AES256 for the service user in AD, and doing so has no adverse effect on the existing SPNego implementation. You can also regenerate the keytab file and see in the contents of the file that the new encryption protocols are included (note that you need the "unlimited" JCE policy files in your JRE to generate AES256 keys). However, when you go to upload the new keytab in the SPNego Wizard, only the RC4 key will be available to import.
In my example here, I am enabling SSO on a NetWeaver 7.01 AS Java system, so RC4 remains the best option, unfortunately. Nevertheless, for those with portals on a higher NetWeaver version, I would strongly encourage you to turn on AES and use it.
Bad news but good to know. Thanks a lot for your research Matt!
I am starting to play with some Java test systems. This blog is making my life a lot easier.
Glad to hear it, Cris! Hearing that is the best reward for writing it.
thank you for this detailed documentation. I am trying to configure SAP SSO 3.0 for SPNEGO to a SAP Portal with own user store.
You wrote "At a later time I will follow up with a blog about how you can set up SSO to work for mismatched usernames as well". I am looking for a documentation of this. The Guide "SecureLoginforSAPSSO3.0_UACP" is not very detailed at this point.
Can you recommend further documentation?
Unfortunately, I never did get to writing that follow-up blog about mismatched usernames, as I never did get around to configuring that in my organization. As so often happens, other priorities took over. The areas of interest that I planned to research and experiment with involved finding a way to have a mix-and-match of username-matching and email-matching. In the end, it might become purely email-matching as a replacement for username-matching.
In addition, another follow-up item for me is to move away from the obsolete RC4 encryption algorithm and up to AES256. Since the time when I wrote this blog, I have upgraded our Portal to NetWeaver 7.5, so the incompatibility I encountered (and mentioned in comments above) should now be a non-issue. One nice point is that the upgrade itself did not break anything in the SPNEGO configuration; it just kept on working without any particular effort on my part.
If you get this figured out, please do come back and let us know what you found.
It's been quite some time now....but Do we still have step by step doc configuring sso 3.0 automatic authentication between windows ad users and portal by spnego...etc portal use and windows user id are mismatch..
In fact, I never did get to writing that follow-up I promised about how to do this for Windows and SAP username mismatches. And, in fact, we still haven't solved this in our own organization.
But not because it isn't solvable. I'm pretty sure I know how to achieve it. But I've been so swamped here that it has been pushed down the priority list for us. And, I'm not willing to blog about how to do something that I haven't myself done.
Still, I believe the trick will be to focus on something other than username as the matching attribute. A good choice would probably be email address. Currently we use RSLDAPSYNC_USER as a nightly scheduled job to keep the email address (as seen in SU01) matched with the email address in AD, but that too requires some customization. In AD we configured a Custom Attribute (CustomAttribute5, in our case) to hold the SAP username, and we auto-populate that via a custom SAP job that extracts this from the Infotype 0105 (subtype 0001) property on the employee record (as seen in PA20), using Employee ID as the matching attribute (which we also push out with a custom job).
So, it takes some customizing, as you can see, but once you have alternate fields in AD that can be used as a match, then I believe it should be possible to reconfigure SPNEGO to look on that field instead of the username.
But, again, and as a caution, I have not yet tried this. It's an hypothesis.
i have one question on SPNego config in Portal, if we enable the SPNego in Portal, if administrator wants to login with different admin account, is it allows to login here? is there any other setting we need to enable in browser or Portal side.
please let me know your thoughts on this
I addressed this in the blog, very close to the end. It's indexed at:
Short answer: yes, you can do this. You simply append ?spnego=disabled at the end of your URL.
i did try to login with admin account with given comment. but its not working for me.
It's not clear to me what you mean when you say it's not working for you. Do you mean that you get authenticated by SSO whether you add the 'disabled' command in the URL or not? If you are getting a logon screen when you add the 'disabled' command, then it's working.
Or do you mean that your password for alternate administrator account isn't working? If so, that's an entirely different issue, unrelated to spnego or SSO.
You might want to try raising this as a question in the SAP Single Sign-On and/or NW Java Security and User Management tags.
sorry for the confusion here. sso was working fine with out any issues. but when ever am trying to login with administrator account, its not showing me the logon screen, even i put the disable comment at end of the url.
i tried in IE and Chrom browser as well, still it not giving me the option for login screen.
Three possible reasons come to mind.
First, make sure you are entering the disable command properly. Here is an example from our own internal employee portal (host and domain obscured for privacy, of course):
Note that “?spnego=disabled” immediately follows the end of the usual URL, with no extra characters like /, etc.
Second, make sure your authentication stack includes the BasicPasswordLoginModule in the right place. It should look pretty much like this:
See https://blogs.sap.com/2016/02/08/single-sign-on-for-java/#jive_content_id_Login_Modules_and_Flags for more information.
Third, make sure you have configured a Logoff Redirect URL. See https://blogs.sap.com/2016/02/08/single-sign-on-for-java/#jive_content_id_Logoff_Redirect_URL for more information.
thanks Matt! its working fine now.
Hello Matt, Thanks for this post it's working fine for us on our Test Portal with an ECC Backend..
Our Landscape: NetWeaver 7.5 Portal for ESS with connection to ECC 6.0 EHP8 for UME and WebDynPro ABAP programs.
Would the above scenario require a license if it's only used for Portal and Not SAPGUI / WEBGUI?
You mention a license is required:
If you are planning to implement an SSO scenario involving your ABAP system
This is a versatile tool that can help you implement SSO for SAPGUI, for WebGUI, and for the various web-based applications you might run on an ABAP system (such as SRM, for instance).
Question, Can you point me to documentation or something that talks about licensing. I need to Provide documentation to my Supervisor that says that we don't have to purchase/License the SAP SSO Appliance to implement this in our landscape..
Please let me know if you need more information on our landscape setup..
Thanks for you help..
Licensing questions are... tricky. Strictly speaking, we can't really answer such questions in the Community, because there is no one-size-fits-all answer. Every customer has their own licensing agreement with SAP, negotiated with your account rep, so what might be true for licensing at one customer may not be true at others. That's not to say that there aren't standards applied, it's just that you may have negotiated something different.
My understanding is that you only need to license the SAP SSO Appliance if you intend to setup single sign-on using SAPGUI, and that SPNego for your Java systems is fair game without it, and that's what I stated near the beginning of this blog. But, you cannot take that as a definitive answer. Also, it has been 4-1/2 years since I wrote that.
If you want something that would represent official documentation you can give to your corporate management, I think you'll probably need to get that from your account rep. And yes, you might need to educate your account rep first on just what it is that you are talking about, since they usually are not technical people.
There probably is documentation out there that says this. I probably found it five years ago before going down this path myself. Unfortunately, I no longer remember where I found this, and in any case, SAP's websites have changed dramatically in the meantime.
Please note, when I say SSO for ABAP systems in this context, I am specifically referring to an integrated authentication scenario for SAPGUI. I am not referring to pass-through authentication that occurs to an ABAP backend system from a Portal user, where a Logon Ticket is used, and your ABAP system is the UME for your Portal system. There is definitely no extra license requirement for that, and this is a very standard and common setup.
I hope this helps.