Author Topic: Repository authentication through PCS  (Read 2303 times)

ppeeters

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Repository authentication through PCS
« on: April 19, 2024, 10:07:29 pm »
Hi all,

We recently moved our on-premise DB repository where Windows authentication was activated to a cloud-based repository using PCS for Sparx EA access. We keep the Windows authentication settings but add an OpenID option using our Azure AD (now Entra ID) IdP synchronized with our on-premises AD.
I'm not an expert in Windows domain security therefore I'm not sure I'm using the correct wording.
Connecting from within on-premise, the Windows authentication is "propagated" to PCS and authentication succeeds as usual using the AD group mapping defined.
However, if we try to connect from home (without any VPN), windows authentication fails and Sparx EA proposes an OpenID authentication (which succeeds).
Not being familiar with the Windows ID propagation, is it the expected behavior? Does Sparx EA try to negotiate with the on-premise AD and fail? If yes, this means then that OpenID is the only authentication method available remotely. This is not a problem but our users might be surprised by this behaviour.

Thanks for your clarification.

BobM

  • EA User
  • **
  • Posts: 139
  • Karma: +8/-0
    • View Profile
Re: Repository authentication through PCS
« Reply #1 on: April 19, 2024, 11:09:05 pm »
Hi,

No it should be perfectly possible to connect to PCS without VPN from anywhere using SSO based on the browser credentials you are using.

Authentication should be set to model, AD group with respective access rights should be linked to the model, only allow latest TLS version
I'm not a security expert neither but I do recall they had to ensure our certificates were not required to be installed locally on each PC

Best regards

ppeeters

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: Repository authentication through PCS
« Reply #2 on: April 22, 2024, 04:35:26 pm »
Hi all,

Thanks for the precision. I have collected the log from the "System Output"

Using Sparx EA 16.1.1625 (64bits)

PCS is hosted and managed by prolaborate (AWS)

Connect from corporate network :

Quote
Attempting to log in Windows SSO user: 'my login name'
Checking for user's Windows linked groups
User is a member of Windows groups: followed by the list of 70+ AD groups I'm member of
User's Windows groups linked to Enterprise Architect groups: the AD group authorized to use the repository <-> Authors
User's Windows groups not linked to any Enterprise Architect group: list AD groups not mapped to any repository group
Login: Logged in as Windows user 'my login name'.

Now connecting from a home using public network (same PCS endpoint, same repository security configuration)

Quote
Attempting to log in Windows SSO user: 'my login name'
Failed to get current user from Active Directory.
The specified domain either does not exist or could not be contacted.

Login: Non-Domain users are not allowed (username: my upn login)
Attempting to log in OpenID SSO user
and the OpenID dialog shows up.

Configuration is:
  • accept windows authentication
  • accept OpenID authentication
  • automatically create and modify windows or openid users
  • One AD group is mapped to one repository group both for windows authentication and openid

Should I autorise non-domain users ?

BobM

  • EA User
  • **
  • Posts: 139
  • Karma: +8/-0
    • View Profile
Re: Repository authentication through PCS
« Reply #3 on: April 22, 2024, 05:50:45 pm »
Hello,

In our company we use a specialized AD group for externals who need to consult PCS
We deliberately chose not to engage in OpenID as apparently according to our security team it is possible to hijack access validation via simple scripts.

ppeeters

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: Repository authentication through PCS
« Reply #4 on: April 23, 2024, 06:53:31 pm »
Hello,

In our company we use a specialized AD group for externals who need to consult PCS
We deliberately chose not to engage in OpenID as apparently according to our security team it is possible to hijack access validation via simple scripts.

Interesting! Do you have any references ?
BTW, our repo is not open to people outside our organization. OpenID authentication relies on our corporate IdP using dedicated groups.