J2EE X509 mapping

[Former Member]

I want to follow up on a sub-topic that came up in this thread:

What concerns us is this:

In a J2EE X509 SSO scenario, we have a few choices to map user IDs to X509 certs. Our PKI is such that when a user logs into their PC, their roaming profile places their X509 certificate in their IE certificate store. This cert then gets used for a variety of enterprise apps, including SAP. It works as long as the user is at a PC they logged into. If they go to a public PC, like in a conference room, then they are aware that they have to log in manually since the conf. room uses a generic login.

For our environment of around 10,000 named users, we have them all mapped in our ABAP system table USREXTID. This is done automatically through a job that populates that table with data from our LDAP. The entry is simply CN=xxxxx and it's mapped to the SAP login ID.

This method is not possible with the J2EE side of things. Instead, the UME admin can manually import a client cert. We did that and it works.

Or, we can have the user map it themselves by clicking the "Certificate Login" link on the initial login screen and then authenticate themselves, which in turn populates their cert info into their UME record.

It is that method that concerns us. What's to stop user A from logging into his PC with his cert and then having user B come over and log into the app, subsequently perform that automatic mapping? User A would have user B's authorizations in future sessions on his own computer. We tested this and it is a technical possibility. Also if a cert is already mapped and a user clicks the "certificate login" button, then a new cert overwrites the old cert.

With our job that automatically maps CN=xxxxx info to SAP Logins in ABAP, this risk is completely eliminated. Only a user logged into their own PC, with their own Windows/XP credentials, can access the SAP app with their cert.

Please help me understand if I am missing something that eliminates the risk I've pointed out.

[Former Member]

I want to follow up on a sub-topic that came up in this thread:

What concerns us is this:

In a J2EE X509 SSO scenario, we have a few choices to map user IDs to X509 certs. Our PKI is such that when a user logs into their PC, their roaming profile places their X509 certificate in their IE certificate store. This cert then gets used for a variety of enterprise apps, including SAP. It works as long as the user is at a PC they logged into. If they go to a public PC, like in a conference room, then they are aware that they have to log in manually since the conf. room uses a generic login.

For our environment of around 10,000 named users, we have them all mapped in our ABAP system table USREXTID. This is done automatically through a job that populates that table with data from our LDAP. The entry is simply CN=xxxxx and it's mapped to the SAP login ID.

This method is not possible with the J2EE side of things. Instead, the UME admin can manually import a client cert. We did that and it works.

Or, we can have the user map it themselves by clicking the "Certificate Login" link on the initial login screen and then authenticate themselves, which in turn populates their cert info into their UME record.

It is that method that concerns us. What's to stop user A from logging into his PC with his cert and then having user B come over and log into the app, subsequently perform that automatic mapping? User A would have user B's authorizations in future sessions on his own computer. We tested this and it is a technical possibility. Also if a cert is already mapped and a user clicks the "certificate login" button, then a new cert overwrites the old cert.

With our job that automatically maps CN=xxxxx info to SAP Logins in ABAP, this risk is completely eliminated. Only a user logged into their own PC, with their own Windows/XP credentials, can access the SAP app with their cert.

Please help me understand if I am missing something that eliminates the risk I've pointed out.

[yonko_yonchev]

Hi David,

This scenario is only possible if userA's certificate is not mapped to any acount in the UME data source. Only in this case will userB be prompted for user id/pass and a mapping will occur.

If UserA's certificate is already mapped to userA's account, then userB will automatically be logged on as userA on userA's workstation.

Even assuming that somehow userB manages to get the system to map userA's certificate to his account, while it is also mapped to userA's account, AFAIK the UME will throw an exception that it cannot positively determine the user from the certificate, just because there are two matches.

Regards,

Yonko

[Wolfgang_Janzen]

> It is that method that concerns us. What's to stop

> user A from logging into his PC with his cert and

> then having user B come over and log into the app,

> subsequently perform that automatic mapping? User A

> would have user B's authorizations in future sessions

> on his own computer.

Well, according to your description the same certificate (which belongs to user A) would then be mapped to two accounts (i.e. the one of user A and another one of user B). So, when trying to logon with the X.509 client certificate (of user A) the server would determine that the mapping is ambiguous.

But I agree with you: users might not be aware of the consequences if they logon (with their SAP userID and password) on a (foreign) PC where another person is currently logged onto (on the operating system level). Of course, they should have logged off from the OS level and re-logon entirely. But I'm pretty sure that most of them will not know about the consequences of taking the shortcut ...

Of course, setting the mapping (rules) on the server side is the best approach. By that the user will not have any chance to influence the mapping.

Best regards, Wolfgang

[yonko_yonchev]

As I pointed out, the system won't perform any mapping. Given userA's certificate is already mapped in the UME data source, userB will automatically be logged on as userA on userA's workstation and userB won't get a prompt to enter user Id/password.

For example, with the login module stack config from the documentation what will happen is this:

EvaluateTicketLoginModule doesn't find a ticket

ClientCertLoginModule finds the certificate for userA => userA is authenticated

CreateTicketLoginModule creates a ticket for userA

Authentication check completed, userA is authenticated

No further authentication checks are performed. UserB will use the originally called application with userA's authorizations.

In other words, due to the order of the login modules in the login module stack and their processing flags, automatic mapping is performed in the authentication flow only when the system cannot authenticate a user from the certificate.

[Former Member]

You are correct. Take it a step further now...

user A has a cert on his PC and it's mapped to his account.

user B has a cert on his own PC, but has not mapped to an account yet.

user A goes to user B's computer and click's the 'certificate login' button.

he authenticates his account to user B's certificate.

I tested this and it works as i described - what happens is the user A cert in user A's account is <b>replaced</b> with the user B cert. There isn't even a warning, it just happens.

[yonko_yonchev]

Well, with this additional step userA can only log on as userB under userB's profile on userB's PC. If userA were to go to another PC he would also have to take userB's private key with in order to log on as userB. Given userB's private key is to be used only by userB (according to PKI) and with the right ordering of login module stack, userA shall get a log on prompt to enter userID and password on that other PC.

If the browser on that other computer has access to userA's keypair, then the userA logon will remap userA certificate to userA's account (overwriting userB's). If it doesn't then an administrator will have to do it manually.

In either of the above cases userA will be logged on as userA, and based on the user Id/password info.

In conclusion, I agree it would be nice to have a warning that the certificate is to be replaced, though, my guess is that this will have an adverse effect on the speed of the whole process. May be this will be added as a feature later on.

[Wolfgang_Janzen]

> user A has a cert on his PC and it's mapped to his account.

> user B has a cert on his own PC, but has not mapped to an account yet.

> user A goes to user B's computer and click's the 'certificate login' button.

> he authenticates his account to user B's certificate.

Yes, but that sounds like: user A "donates" his account to user B.

Notice: user B (and only him has access to the private key of his certificate) can then logon (with his X.509 client certificate) under the account of user A.

> I tested this and it works as i described - what happens is the

> user A cert in user A's account is <b>replaced</b> with the user B cert.

> There isn't even a warning, it just happens.

Well, that's because of being able to update the certificate mapping.

Notice: certificates do have a limited lifetime - they will expire sooner or later. A follow-up certificate is supposed to substitute the previous one. In most cases the subject name will remain unchanged - but that's not guaranteed ... (it might be more than just the sequence number that has changed).

Regards, Wolfgang

PS: "CERTMAP" is just an offer - it might not be suitable in all cases (e.g. in such cases where a PC is not really a "Personal Computer" but used by different users without logoff from the OS level before handing over the PC to the next person - which will also allow that person to gain access to the Outlook inbox, file shares, etc.).