AnsweredAssumed Answered

Authentication Sources - Web Services

Question asked by Andrew Beauchamp on Nov 10, 2017
Latest reply on Nov 12, 2017 by Andrew Beauchamp

Like • Show 0 Likes0
Comment • 5

Hello Experts.

RSA G&L Version: Version: 7.0.0.101393 P01

My goal is to create a new authentication source for service accounts only to make web service calls.

And I've followed both RSA Link community questions to the letter but there is something not quite right.

IGL Service Accounts

How to create local-account in aveksa (other than AveksaAdmin) to bypass SSO

Here is the basic setup:

1. Have the service account live in our Active Directory and collect the accounts with a specific "service account collector"

2. Create an identity specifically for this service account and mapped the accounts together

3. Create an authentication source using type "RemoteADAuthenticator" and associating the

specific "service account collector"

All this is kinda working as expected and test ok - see screenshot... but I'm not able to login using webservice calls.

"Successfull test of Login for user: ..." screenshot

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

i.e. /aveksa/command.submit?cmd=loginUser&format=json

with payload <username>account</username><password>password</password>

<html><head><title>Error</title></head><body>User could not be validated. The username or password may be incorrect. Query String=cmd=loginUser&format=json</body></html>

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

I've tested the hell out of this - and it seems that only ONE of the FIVE authentication sources will work with web services loginUser call.

If I move the service account to the account collector which I know is working - it's works a perfectly. When I move it back to the correct collector no luck - even tho it test (as above) well and I can login directly to the app.

They are all mapped to unique account collector and the only thing I can think of is that are all authenticated to the same domain.

Any help would be appreciated.

Cheers, Andrew

Boris Lekumovich

Nov 12, 2017 9:01 PM

Correct Answer

If you don't see the following section in the Web Services description, then you might not have it yet.

I'm not 100% sure, but I think it was introduced in v7.0 P2

See the reply in context

No one else had this question

Outcomes

Tahir Ahmed Nov 10, 2017 2:33 AM

Try passing authsource variable in loginUser cmd and try.

<username>value</username>* - The username used to log in.
<password>value</password>* - The password used to log in.
<authsource>value</authsource> - An optional auth source provider name used to log in with such as an ldap provider. This can included as an URL parameter alternatively.

An example url (POST) used to invoke this command is shown below:

https://<server-ip>:<port>/aveksa/command.submit?cmd=loginUser&authsource=MyAuthSource

with post content

Actions

Andrew Beauchamp @ Tahir Ahmed on Nov 10, 2017 6:46 AM

Thanks Tahir.

I gave this a try in the following scenarios but no luck.

With "authsource" as a parameter i.e. cmd=loginUser&authsource=Service_Account
With "authsource" as in the body with xml i.e. <authsource>value</authsource>
Both in the body and parameter

Actions

Andrew Beauchamp @ Tahir Ahmed on Nov 12, 2017 8:54 PM

Ok after some more testing - it looks as if the authentication via web services is prioritised by alphabetical order.

To prove my hypothesis -

I pulled my logs file from the aveksaServer.log - and I see that is it clearly authenticating to the incorrect

source I'm seeing this name "source-name=Active Directory AUS ADC" in the logs for my service account.

I delete all my authentication sources - except of service account auth source. And it works. I'm seeing "source-name=Active Directory Service Accounts ADC" and i'm getting a valid token.

When I re-create AND re-name the original auth sources with a 'z' in front of the name "source-name=zActive Directory AUS ADC" the situation is reverse. Service Account will auth for web services and not general LAN accounts. I can also see the incorrect auth sources being reference in the logs.

The addition value in the payload for web service call did not work - it's not documented in the Admin -> Web Services so I'm wondering it might not be applicable to my version....? Can anyone confirm?

<username>value</username>* - The username used to log in.
<password>value</password>* - The password used to log in.
<authsource>value</authsource>

Thanks in advance. Andrew

Actions

Boris Lekumovich

@ Andrew Beauchamp on Nov 12, 2017 9:01 PM

If you don't see the following section in the Web Services description, then you might not have it yet.

I'm not 100% sure, but I think it was introduced in v7.0 P2

1 person found this helpful

Actions

Andrew Beauchamp @ Boris Lekumovich on Nov 12, 2017 9:11 PM

You're right as suspected.

Thanks Boris.

Andrew

Actions

5 Replies

Tahir Ahmed Nov 10, 2017 2:33 AM
Mark Correct
Correct Answer
Try passing authsource variable in loginUser cmd and try.
- <username>value</username>* - The username used to log in.
- <password>value</password>* - The password used to log in.
- <authsource>value</authsource> - An optional auth source provider name used to log in with such as an ldap provider. This can included as an URL parameter alternatively.
An example url (POST) used to invoke this command is shown below:
https://<server-ip>:<port>/aveksa/command.submit?cmd=loginUser&authsource=MyAuthSource

with post content

<username>user</username><password>pass</password>
Like • Show 0 Likes0
Actions
- Andrew Beauchamp @ Tahir Ahmed on Nov 10, 2017 6:46 AM
  Mark Correct
  Correct Answer
  Thanks Tahir.
  
  I gave this a try in the following scenarios but no luck.
  
  With "authsource" as a parameter i.e. cmd=loginUser&authsource=Service_Account
  With "authsource" as in the body with xml i.e. <authsource>value</authsource>
  Both in the body and parameter
  Like • Show 0 Likes0
  Actions
- Andrew Beauchamp @ Tahir Ahmed on Nov 12, 2017 8:54 PM
  Mark Correct
  Correct Answer
  Ok after some more testing - it looks as if the authentication via web services is prioritised by alphabetical order.
  
  To prove my hypothesis -
  
  I pulled my logs file from the aveksaServer.log - and I see that is it clearly authenticating to the incorrect
  source I'm seeing this name "source-name=Active Directory AUS ADC" in the logs for my service account.
  
  I delete all my authentication sources - except of service account auth source. And it works. I'm seeing "source-name=Active Directory Service Accounts ADC" and i'm getting a valid token.
  
  When I re-create AND re-name the original auth sources with a 'z' in front of the name "source-name=zActive Directory AUS ADC" the situation is reverse. Service Account will auth for web services and not general LAN accounts. I can also see the incorrect auth sources being reference in the logs.
  
  The addition value in the payload for web service call did not work - it's not documented in the Admin -> Web Services so I'm wondering it might not be applicable to my version....? Can anyone confirm?
  
  <username>value</username>* - The username used to log in.
  <password>value</password>* - The password used to log in.
  <authsource>value</authsource>
  
  Thanks in advance. Andrew
  Like • Show 0 Likes0
  Actions
  - Boris Lekumovich @ Andrew Beauchamp on Nov 12, 2017 9:01 PM
    Unmark Correct
    Correct Answer
    If you don't see the following section in the Web Services description, then you might not have it yet.
    
    I'm not 100% sure, but I think it was introduced in v7.0 P2
    1 person found this helpful
    Like • Show 1 Like1
    Actions
    - Andrew Beauchamp @ Boris Lekumovich on Nov 12, 2017 9:11 PM
      Mark Correct
      Correct Answer
      You're right as suspected.
      
      Thanks Boris.
      
      Andrew
      Like • Show 0 Likes0
      Actions

Authentication Sources - Web Services

Outcomes

Related Content

Recommended Content

Incoming Links