AnsweredAssumed Answered

Creating a SMSESSION without credential/password

Question asked by stephen.mcgilligan on Sep 29, 2015
Latest reply on Nov 6, 2015 by stephen.mcgilligan

Hi,

 

We have a business requirement that uses OAuth (via the Axway/Vordel API gateway) to implement extended login. As this API gateway has an interface into SiteMinder via the agent SDK we would like to use it to generate a new SMSESSION for the user, for a small subset of lower auth level resources, if all the OAuth checks are successful. The only sticking point is that on follow up OAuth access requests within the extended login period the user's credential will not be available. Hence we need to be able to make the call into SiteMinder (or CA Single Sign-On I suppose ) to generate a user session without the user's password.

 

I'm almost sure I've seen this done in the past but I think it needed a custom authentication scheme. Looking at the SDK document it looks like those calls need to follow the normal IsProtected/IsAuthenticated/IsAuthorized sequence so nothing to expose the "create session" function which makes sense as that's a pretty powerful function.

 

We could have a user directory definition (ODBC) that called an authenticate procedure to ignore passwords i.e. always return success when only the username is passed. However, this would need a LOT of thought around securing the ability to authenticate against that user directory. Obviously we are going to have to trust the API gateway completely and can lock down that policy so only they can validate against the user directory definition. However, if they want to use that session to access other resources we would need to extend those policies and ensure normal login screens cannot authenticate against the new user directory, only authorise...maybe directory mapping.

 

Another thought is impersonation. So the API gateway programmatically becomes the "help desk" user. They use a set of credentials to authenticate against SiteMinder and then impersonate the end user (from the OAuth validation) to pick up an "end user" SMSESSION which can in turn be returned to the end user client and be used to access the subset of SM protected resources. From a security perspective keeping the "help desk" credentials secure is very important here. Are there any other gotchas?

 

Apologies for the scatter of information. Just throwing a lot of things out there to see what the community think.

 

Many thanks,

Stephen

Outcomes