Where are user passwords stored?

[horszasz]

Shh!

Don't start pointing out the complete absence of anything like security in this product.
All that will get you is shat on from a dizzying height.

/U

Agree with you. Security is clearly one of EA's main weakness. I am using ea since its version 9, and i ask Sparx every year to develop enterprise grade autnetication method.

Sparx Systems should realize, that their product is also used by large enterprises, where identity management and security is a key factor of working. It would not be a very hard challenge to develop an ldap based authentication in 2020!

I think, Sparx's luck is, that enterprise clients realize this weakness of EA tipically only after the purchase...

[qwerty]

I think, Sparx's luck is, that enterprise clients realize this weakness of EA tipically only after the purchase...

If at all.

q.

[Geert Bellekens]

I'm not sure I'm following.
You can use
- username and password
- Windows Authentication
- OpenID

The last two seem like enterprisey enough no?
Since v15.1 you can also simply link your EA security groups to AD groups, without the need for double maintenance of users.
For larger clients this is a major improvement.

Geert

[horszasz]

Hi Geert,

I am of a different opinion

-Windows Authentication: yes, it's a good stuff. But it is strong restricted, where and how you can use it, and (to tell the truth) I'm afraid EA's WinAuth is not a really well-designed and fully elaborated solution (!!!it's just my feeling, not a fact!!!!)
- OpenID is dead (and it is questionable if it was ever alive) 

Cheers,
Gergely

[qwerty]

Once again: EA security is NO security. It's some accidental deletion prevention (which might be ok if applied the right way). But in no way this has to do anything with security. Blocking the main entry with a panzer and having the backdoor completely unsecured - well, would you trust that bank your valuables?

q.

[Geert Bellekens]

I don't entirely agree with you on that.

We use WVD (the new remote desktop) to publish the application and SQL server as database. All access is to WVD, SQL Server and Enterprise Architect is set to Windows Authentication, this this is really single sing on.
The way we do it we have Active Directory groups in different levels to control access to the application and its functions.

- EA Application Group (these users get the application published wia WVD (the new remote desktop))
  - EA RepositoryA Group (these users get read/write access on the database level )
     - EA RepositoryA Admin
     - EA RepositoryA Read/Write
     - EA RepositoryA Read-only
  - EA RepositoryB Group (these users get read/write access on the database level )
     - EA RepositoryB Admin
     - EA RepositoryB Read/Write
     - EA RepositoryB Read-only


The entire user management is now a first level service desk process (with some self-service automated processes as well for approved accesses)

All we need for a user to have access is that the user in the right Active Directory group. If the user is no longer in the group the access is actomatically revoked.

I consider all of that a major part of Security.

Now once you are part of the database read/write group, you can in theory do anything.
The Admin, Read-Write, Read-only EA specific groups are more there to protect the users against themselves.
If we don't want regular users to do xmi import, or create their own stereoypes, we can restrict that in these groups.
I think mostly this is sufficient.
Is it going to stop someone with mall intent, that has access to the database, to wreak some havoc? No, but that why we have backups etc..

Is it enough to be useful in "normal" (99,9%) cases? Yes

With a setup like this I'm no longer embarrassed to present this to the security responsible in the organization.

Geert

[Uffe]

Taking a deep breath and wading back in...

The entire user management is now a first level service desk process (with some self-service automated processes as well for approved accesses)
All we need for a user to have access is that the user in the right Active Directory group. If the user is no longer in the group the access is actomatically revoked.
I consider all of that a major part of Security.

Absolutely. Getting rid of obsolete user credentials is very important, and being able to do manage access using nothing but standard OS tools is also very important.

Now once you are part of the database read/write group, you can in theory do anything.
The Admin, Read-Write, Read-only EA specific groups are more there to protect the users against themselves.
If we don't want regular users to do xmi import, or create their own stereoypes, we can restrict that in these groups.
I think mostly this is sufficient.
Is it going to stop someone with mall intent, that has access to the database, to wreak some havoc? No, but that why we have backups etc..

I think you're confusing security with robustness there. Security is not primarily concerned with continuity and things breaking, it is concerned with preventing unauthorized access (leakage) and malicious updates (misinformation).

You can delegate control over access to the information to the DBMS and the AD, which is good. But you don't have to, and from a security perspective, that's bad. It means you have to instruct IT do do it right while leaving them the option to do it wrong, and that adds another link in the chain.

It's also massively annoying that EA chooses to refer to its user roles, which restrict access to functionality but not to data, by the term "user security." It's not security. It's nothing to do with security. So right out the gate that's something you have to explain to the IT security people. You might not be embarrassed by that -- I am. 


/U

[Geert Bellekens]

I agree that the term "User Management" would have been better then Security

Geert

PS. With PCS and SQL Server or Oracle, you can apparently restrict access to data as well. This works with the row level security on database level.
Never tried it myself, but might be interesting if you have a use case for it.