Authentication and Authorization Web Service Session Tokens

[Chris Bertagnolli]

Anyone know if it's possible to utilize the token value from a standard Web Agent cookie against the CA provided authentication/authorization web services?

 

-----------------------------

High Level Example

I've got 1 Web Agent application: standard web based application. And I've also got 2x applications hosting up some web services/other functions that I need to call outside of the browser and on behalf of the user.

 

I've already got an SPS hosting up the authentication and authorization web services for SOAP/REST.

 

Setup:

- AuthN/AuthZ SPS (SPS)

- Web Service App (ServiceApp)

- Web Agent App (UserApp)

- 1x Authentication directory

 

Desired Flow

- I access UserApp and log in to obtain SMESSION

- I select resource /myrequests

- UserApp takes the value of SMSESSION and passes to ServiceApp (contains appid + resource)

- ServiceApp forms SOAP and sends token+appid+resource to SPS

- SPS responds with success to ServiceApp (contains username, etc)

- ServiceApp returns requested functions to UserApp (whatever logic is built in)

- UserApp services up content

- I successfully access /myrequests

-----------------------------

 

So, the above doesn't work currently since every time the SMSESSION token value is passed to the Web Services it always denies authorization. IF I pass a Web Services token generated for appid1 --> appid2/3/4..so on, it works fine. But Web Agent token --> Web Services fails. It's not clear exactly what fails or why, but the logs just show 'authentication failed'.

 

Essentially I want to use the single token value, whether Web Service generated or Web Agent generated.

 

Am I missing something really obvious? Is this possible?

[Chris Bertagnolli]

Going the other way and passing the session generated by the Web Service to a Web Agent in the header, generated "unable to process SMSESSION cookie"....Does the Web Service use a different key to encrypt/decrypt session tokens? Everything is using the same Policy/Key Stores so thought it'd all align in terms of handling each others session values.

[Legacy User]

Hard to digest that it wouldn't work - it should ideally.

 

Also have we checked the WA ACO does not have any stringent security constraints which are applied on the SMSession. Are we using a simple OOB ACO duplicated off a DefaultAgentConfiguration Object for the UserApp WA.

 

Regards

 

Hubert

[Legacy User]

I have a feeling that the SessionToken != SMSession, better to post an RFI to CA Support and have them validated with CA Single Sign On Engg.

[Chris Bertagnolli]

Yeah, I was kind of wondering that same thing. In terms of functionality it would be great if they were the same since it makes passing it around much easier when you've already got an app fronted with a Web Agent and users dragging around a session cookie value. At that point any other app on the domain/sub-domain would have access to it and be able to use it to bounce off the web services for authorization on behalf of some user if necessary.

 

Not sure what other values could even be used (serverssionspec isn't it or sessionid); Unless the session tokens by the SPS are completely separate entity and cannot be used elsewhere...which would be a little annoying but I suppose manageable.

[Chris Bertagnolli]

ACO is a slightly modified IISDefault copy

 

Web Service ACO

CookideDomain = mydomain.com

TransientIPCheck = no

UseHTTPOnlyCookies = yes

UseSecureCookies = yes

validtargetdomain = mydomain.com

EnableAuth = yes

EnableAz = yes

 

UserApp ACO

CookideDomain = mydomain.com

TransientIPCheck = no

UseHTTPOnlyCookies = yes

UseSecureCookies = yes

validtargetdomain = mydomain.com

[jack.saunders]

Yes this should work. I have attached some sample requests in case maybe your request elements are a little different.

Attachment(s)

Sample SOAP+REST AuthAZ API requests.docx   156 KB 1 version

[Chris Bertagnolli]

Thanks for the examples. Our standard Web Service requests work fine. The issue is attempting to cross Web Agent session and Web Service session.

 

I want to take a session token created by a Web Agent and pass it off to the Web Service for authorization. What I don't want is having to authenticate the user again directly against the Web Service to get a new token, they were already authenticated when going to the Web Agent. That would allow our web based applications to interface, relatively painlessly, with other services on behalf of the user without requiring re-auth. This does not appear to work thus far. I've passed the SMSESSION cookie value itself, sessionspec and any other value I could find that looked like a session id....all failed.

 

When doing that the authentication service results in "Authentication Failed" 100% of the time and authorization services as "Not Authorized" 100% of the time.

 

If the sessions created between a Web Agent and the SPS are using different keys, then that could certainly be a problem. However, it's not clear from what I've read what key is being used by the SPS to generate the session token it returns (I assumed the same key the others use from the key store [and they share a common one]). If it's a separate key then would have to make sure it matches what is in the key store as well.

[jack.saunders]

It is certainly the same keys if the SPS agent and web agent share the same policy severs / keys store.

 

Enable the agent trace log to get more detail on why it is failing.  Also policy server trace log.

[Chris Bertagnolli]

On the Policy Server side it just acts as though it's attempting a user authentication and fails when a session token is passed to it from a Web Agent

 

[01/30/2015][14:52:36][3692][][SmAuthUser.cpp:5069][CSmAuthUser::AuthenticateUserDir][][][][][][][][][][][][Leave function CSmAuthUser::AuthenticateUserDir]

[01/30/2015][14:52:36][3692][000080fe000000002eeffc0834e3991-1cd0-54cef14-16c8-039024a][Sm_Auth_Message.cpp:1751][CSm_Auth_Message::AuthenticateUser][][][][All Users][5][0][][][/][][WebServiceTest][Evaluating OnAuthAttempt policy...]

.
.
.

[01/30/2015][14:52:36][3692][s9462/r6][Sm_Auth_Message.cpp:4649][CSm_Auth_Message::SendReply][][][][All Users][][][][][][][WebServiceTest][** Status: Authentication Attempt Failed. ]

 

 

 

Tracing on SPS was not running so will get that cut on and see if it shows anything different, but a request does get down the Policy Server which returns an authentication attempt failed.That notification above shows every time I play a session cookie value from a Web Agent to the Authorization Web Services.

 

They all share a common key store.

[Ujwol]

Hi Chris,

 

I reviewed your case that you created with support.

One important item that you forgot to mention here is that your security zone IS different in Web Service and User App (Normal Web Agent).

 

After doing some test , I can see what the problem is and how to get this working.

 

Test 1

=======

Web Agent Security Zone : TST , So SSO Token Name : TSTSESSION

SPS Web Service Security Zone : SM (Default ), SO SSO Token Name : SMSESSION

 

Now, on replaying the TSTSESSION generated by web agent in the WebService, it couldn't authenticate the user with the following error in the trace log :

 

[04/16/2015][11:15:27][3396][3876][239b0220000081f50000000081f5239b-0d44-552f0d2f-0f24-036e6784][CSmHttpPlugin::ProcessSessionCookie][SMSESSION cookie - mismatched SSOZone 'TST'.]

[04/16/2015][11:15:27][3396][3876][239b0220000081f50000000081f5239b-0d44-552f0d2f-0f24-036e6784][CSmHttpPlugin::EstablishSession][Failed to process service session.]

 

I also tried setting SSOTRustedZone=TST in WebService , but that still didn't work.

Note, with the normal web agent this would have worked with the SSOTrustedZone setting in place.

 

Test 2

=======

Next, I modify the WebService security zone to match the Web Agent as below :

Web Agent Security Zone : TST , So SSO Token Name : TSTSESSION

SPS Web Service Security Zone : TST , SO SSO Token Name : TSTSESSION

 

Now, on replaying the TSTSESSION generated by web agent in the WebService, it CAN authenticate the user successfully :

 

[04/16/2015][11:20:53][3744][3432][239b0220000081f50000000081f5239b-0ea0-552f0e75-0d68-009c5f90][CSmHttpPlugin::ProcessSessionCookie][Decoded TSTSESSION cookie - User = 'guest', IP address = '155.35.245.129'.]

[04/16/2015][11:20:53][3744][3432][239b0220000081f50000000081f5239b-0ea0-552f0e75-0d68-009c5f90][CSmHttpPlugin::EstablishSession][Service session processing complete.]

 

[04/16/2015][11:20:53][3744][3432][239b0220000081f50000000081f5239b-0ea0-552f0e75-0d68-009c5f90][AuthenticateUser][Validating session '2b83w0pMRE1Kk1wZzreulkC7o1E=' for user 'guest' in zone 'TST'.]

[04/16/2015][11:20:53][3744][3432][239b0220000081f50000000081f5239b-0ea0-552f0e75-0d68-009c5f90][AuthenticateUser][User 'guest' is authenticated by Policy Server.]

 

Next Action

=============

1. Match Security Zone of Web Agent and Web Service

 

Good Luck.

 

Cheers,

Ujwol Shrestha

[Chris Bertagnolli]

Great, thanks for the reply. Seems to confirm Web Agent to SPS Auth service can work.

 

I did check the zones and they match. Which would explain why I can go from SPS -> Web Agent (so long as I have accepttpcookies enabled). If the zones were wrong, that should fail too right?

 

When you installed the SPS and it asked for an encryption key, did you give it your Policy Server encryption key or the 'advanced authentication' key?

 

So our Web Agent / Policy Server environment went from 12.51 -> 12.52 -> 12.52 SP1. During the upgrade to 12.52 it asked for a new "advanced auth" encryption key, which we set. That is the key we then used on the SPS install (straight to 12.52).

 

Also, could you share your application setup and what auth schemes? Are they 'basic' or mix of like basic, forms, etc.

[Ujwol]

Hi Chris,

 

1. When you installed the SPS and it asked for an encryption key, did you give it your Policy Server encryption key or the 'advanced authentication' key?

=> I don't quite remember this. But normally I use a universal encryption key So I believe I would have used the same value.

       However, the Master Key that you provide during the SPS installation should be same as Master Key that you provide during configuration of "Advanced Authentication Server" during Policy server install. Policy server encryption key and the AAS Master Key CAN be different.

 

2. So our Web Agent / Policy Server environment went from 12.51 -> 12.52 -> 12.52 SP1. During the upgrade to 12.52 it asked for a new "advanced auth" encryption key, which we set. That is the key we then used on the SPS install (straight to 12.52).

=>  That is perfectly alright. Moreover, this "Master Key" is used ONLY for the session assurance feature that comes with the "Advanced Authenticaiton" Server. If you are not using Session assurance, you don't even need to bother about it.

 

3. Could you share your application setup and what auth schemes? Are they 'basic' or mix of like basic, forms, etc.

=> I am using only Forms Authentication.

If this is still not working for you , I think key is to get your SPS logs & trace working as that will have all the information of why the sso is failing.

I have seen that sometime the logs from your SPS webservice agent gets mixed up with the SPS default webagent ..have you checked your SPS defaultagent logs & Traces ? I am still figuring out why they are getting mixed up ..

Cheers,

Ujwol

 

[Chris Bertagnolli]

They're patching stuff currently so can be hit-or-miss access on my test systems .

 

I'll see if I can sneak some testing in today and see if it's sticking it in the default Web Agent log. Was hoping to have that all in the last updates I sent but didn't see the log file specified with the authn/authz ACO, didn't think to check default so will give that a go on all my servers are back to being available.

On the Policy Server side it's pretty non-helpful thus far - just showing the user lookup (from the user directory configuration) with an empty user id and saying auth attempt failed.

[Legacy User]

Once a SOAP or REST request is sent to AuthAzWS, the WS then deciphers / translates the SOAP Document into a SiteMinder Agent API Request. Then make a Standard Agent API call via the Java Agent running on SPS. Hence we would see the IsProtected, IsAuthenticated, IsAuthorized call in the SPS WebAgent Trace Log (defined by SPS ACO - remember there is an AuthAzACO and SPS ACO).

 

Yes it did get a while for me to figure this jig saw puzzle. So I am not surprised others are in the same boat.

 

 

Regards

 

Hubert

[Chris Bertagnolli]

Ok, so after getting to thinking of all the ACO's in play I went back to the Web Agent generating the cookie...that seemed to hold the key.

 

The Web Agent being used to generate the cookie has "TrackSessionDomain = yes", this will NOT validate against the AuthN/AuthZ service. If I set it to "TrackSessionDomain = no" then it worked!

 

This has been one heck of a learning experience lol.

[Ujwol]

Good work Chris.

 

However, if you had the SPS webservice agent trace working then identifying this problem would have been a lot easier and quicker.

I quickly tested this in my setup to see what does the SPS Auth/Az webservice agent complains about :

Note : Web Agent Cookie Domain : .ca.com , Web Service Agent Cookie Domain = .example.com

 

[04/20/2015][09:32:54][3576][3820][239b0220000081f50000000081f5239b-0df8-55343b26-0eec-013e4823][CSmHttpPlugin.cpp:1149][CSmHttpPlugin::ProcessServiceResource][Resolved host: 'webservices.example.com:80'.]

 

..

..

..

[04/20/2015][09:32:54][3576][3820][239b0220000081f50000000081f5239b-0df8-55343b26-0eec-013e4823][CSmHttpPlugin.cpp:6136][CSmHttpPlugin::ProcessSessionCookie][TSTSESSION cookie - resolved domain name does not match TARGETH '.ca.com'.]

[04/20/2015][09:32:54][3576][3820][239b0220000081f50000000081f5239b-0df8-55343b26-0eec-013e4823][CSmHttpPlugin.cpp:1967][CSmHttpPlugin::EstablishSession][Failed to process service session.]

[04/20/2015][09:32:54][3576][3820][239b0220000081f50000000081f5239b-0df8-55343b26-0eec-013e4823][CSmHttpPlugin.cpp:1972][CSmHttpPlugin::EstablishSession][No valid session found, exiting with SmNoAction.]

 

Knowing this error would have given us enough hint to find the root cause promptly.

Cheers,

Ujwol

[Chris Bertagnolli]

Yup, it's on now finally (combination of problems as to why it wasn't working). I guess you could also say if there was documented 'working' configurations to compare against would have made it easy as well .

 

Either way, pretty much working now. Still curious why having tracksessiondomain=yes in the Web Agent causes a problem when both are in the same domain...probably just missed something somewhere.

[Chris Bertagnolli]

Just a summary in case anyone else comes across this, might be easier than treading through all the posts .

 

• To share session tokens, a common key must be used (shared key store or same keys exist in separate stores)
  
  
• For a Web Agent to accept a session token generated by the SPS WS (sps web services) you must set "AcceptTPCookie = yes" in the Web Agent ACO
  • Can leverage this to restrict tokens to only the SPS WS or allow them to be used against only some Web Agents; avoids any broad exposure of the SPS WS tokens to be used against other SSO applications.
    
    
    
• For the SPS WS to accept a session token generated by Web Agent, you may need to disable session tracking -- "tracksessiondomain = no" -- in the Web Agent ACO that generates the cookie
  • Still gotta do some testing on that later...but just in case you see issues with it might be worth disabling to rule it out
    
    
    
• You can add custom headers to the returned attributes from the SPS WS response by setting up standard HTTP header variable responses within the associated Application Object
  • This would be the application object tied to the agent / id you had defined
    • Web Services ACO example:
      agent = webservice1,userdataservice
      
      In this case, I would add the headers to the application component for the webservice1 agent. And in my AuthN/AuthZ requests, I would pass the id "userdataservice". If valid, I would get those custom added attributes returned. Same applies to any other agents tied to it.
      
      
• Idle and Max timeouts on the session tokens will be enforced for the 'realm' used to generate it.

 

• The standard RSA Authentication Scheme supplied with SM 12.52 can be used to do two-factor authentication at the AuthN SPS WS
  • Just apply it to the associated application component and pass the pin+tokencode as the "password" ...don't know if it's 'proper' per se, but it works .

            <userName>testuser15</userName>

            <password>mypin+mytokencode</password>

 

• Trace log files for the SPS WS are setup in the Default SPS ACO -- enable them here if they are needed. Enabling them in the SPS WS ACO may not work.

 

• Can have Web Service 1 obtain token to AuthN SPS WS and pass in the authorization header to Web Service 2. Web Service 2 can verify it against the AuthZ SPS WS to verify if valid/authorized.
  • While not 'perfect' does allow fairly straight forward token based authn/authz for lower-risk services where WS-Security etc may be overkill...and without having to have shared secrets all over or passing username+password for basic auth.

 

 

Thanks to everyone for all the input. The default services definitely open up a lot of possibilities without having to go and code all this stuff ourselves! Glad to finally start getting a grasp on them and hopefully our learning experiences can save someone else from having to go through it .

[Shrikanth Mayuram]

I came across same issue and this post saved me lot of time!

Thanks for sharing!