Security in Reusable Asset Service

[Kristofer]

Hi!

I am trying to set up a reusable asset service, but I have some problems understanding the security configuration. It appears that anyone can create and delete a storage, and I cannot figure out how to prevent this.

This is what I have done:

- Installed the Cloud Service (default options)
- Added a database to be used for the RAS (firebird database)
-- For this database, checked the "Accept Queries" checkbox, but nothing else (should I check "Require a secure and..."?)
- Added another database on the cloud server (also firebird) to be used for accessing assets from RAS
-- For this database, checked the "Accept Queries" checkbox, but nothing else
- Opened a cloud connection to the database created in previous step
- Connected to the registry on port 804 (default settings)
- Clicked the "Set Administrator Password" and added a password
- Created a storage and set a password for complete access as well a password for read-only access
- Registered some packages in the storage (successful and unsuccessful depending on which password I used from the step above)
- Closed EA
- Opened the same database/model, connected to RAS and provided the read-only password for the storage created above
- Deleted the previously created storage

What do I need to do to prevent anyone from deleting/adding storages in the registry?
What is the password from "Set Administrator Password"-button used to?

Sorry for basic questions; I am new to the cloud service.

[Uffe]

Hello Kristofer,


I'm afraid you're right: anyone with access to the registry can create and delete storages.

The administrator password is for the cloud service itself, for setting up cloud access to repositories. It's not specific to the reusable asset service, which runs on top of the cloud service.

From what I've heard, the reusable asset service was a third-party product that Sparx Systems bought. As is sadly more usual than not in these situations, it wasn't properly integrated.
In the case of the reusable asset service, this means there are no user security permissions which relate to the service, as there should have been: permissions controlling the ability to create/delete storages should have been added (or possibly the "configure packages" permission could have been extended to cover this). They weren't, so anyone with access can destroy everything by accident.

So the best advice I can give is to minimize access to the registry. You'll have one or more modelling projects as well, so only allow the administrators of those projects access to the registry. Then keep track of what those users are doing, and make sure the RAS repository is backed up often.
I would also advise against using Firebird and instead go with a proper DBMS if you've got more than one or two projects with one or two users in each.

HTH,


/Uffe

[Eve]

http://sparxsystems.com/enterprise_architect_user_guide/13.0/model_repository/set_up_registry_password.html

If a Storage has a Complete Access password, then you can use either the Administrator password or the Complete Access password to modify the Storage

I'm hoping that your administrator password happened to be the same as your read-only password, and that's why you were able to perform a delete. If not, it would be great if you could send in a bug report.

The administrator password is for the cloud service itself, for setting up cloud access to repositories. It's not specific to the reusable asset service, which runs on top of the cloud service.

No, completely different thing. As described in the help I linked to, there is a password for the RAS that explicitly allows creation and deletion of registries.

From what I've heard, the reusable asset service was a third-party product that Sparx Systems bought.

You were probably thinking of:
http://sparxsystems.com/press/articles/CSIRO-Collaboration.html

It says that we developed RAS. Although we incorporated ideas from SolidGround, it is much more widely applicable than that.

As is sadly more usual than not in these situations, it wasn't properly integrated.
In the case of the reusable asset service, this means there are no user security permissions which relate to the service, as there should have been: permissions controlling the ability to create/delete storages should have been added (or possibly the "configure packages" permission could have been extended to cover this). They weren't, so anyone with access can destroy everything by accident.

If the RAS was intended to be included in an existing model, that may make sense. But it would also come with the consequence that at a minimum you would need to create an account for all users, and give them access to read the model as well. The current approach means that you can provide a password and allow anyone to access a single registry. (Either as an author or reader) Trying to manage that with permissions on users would not be so easy.

[Uffe]

No, completely different thing. As described in the help I linked to, there is a password for the RAS that explicitly allows creation and deletion of registries.

... of storages, right?

But yes, my bad. I'd taken "restrict users from creating, modifying and deleting Storages" to mean that users would not be allowed to upload assets (which would be consistent with how the word "update" is used in other EA documentation). Instead, on this occasion, "modify" means "make administrative changes to".

As is sadly more usual than not in these situations, it wasn't properly integrated.
In the case of the reusable asset service, this means there are no user security permissions which relate to the service, as there should have been: permissions controlling the ability to create/delete storages should have been added (or possibly the "configure packages" permission could have been extended to cover this). They weren't, so anyone with access can destroy everything by accident.

If the RAS was intended to be included in an existing model, that may make sense. But it would also come with the consequence that at a minimum you would need to create an account for all users, and give them access to read the model as well. The current approach means that you can provide a password and allow anyone to access a single registry. (Either as an author or reader) Trying to manage that with permissions on users would not be so easy.

I hear what you're saying, but this solution introduces a(nother) whole new permission management scheme. That might be fine in a small-scale, enthusiast-level deployment but it's sheer hell in an enterprise scenario.

/Uffe

[Kristofer]

Thanks to both of you!

Simon,
I tested more today, and I was not able to delete a storage without giving the administrator password for RAS. I noticed however a few things (perhaps by design):

- I could create a new storage without the RAS administrator password.
- There is no button to set the RAS administrator password when using an eap-file nor when connecting from an Oracle repository.
- If you have registered a package using the password for the storage, and immediately after delete it, you are not prompted for the password again. This is probably what was happening in my case and got me confused.

Uffe,
We will continue to use Oracle as in our current setup. I did however notice a problem when accessing our current repository (Oracle) via the cloud service, it did not handle the swedish characters åäö. Have you noticed this as well?