WebEA no longer connecting to models

[Modesto Vega]

Since we switched PCS to use an HTTPS connection and enabled model security, WebEA no longer allows any users to view any models. Every user gets a message reading "error" red font below the list of models in the login screen.

We can also see the following error message in the ProCloud Server logs

Authentication - Windows: user '<Domain Name>\<User Name>' is not valid for model '<Model Name>'

We know this is not the case for some of the users involved.

Any thoughts/help are welcomed.

P.S.: We don't have the same problem with Sparx EA and ProCloud Server.

[Sunshine]

Been a while since I set up prolaborate which sits on top of procloud server. Two things pop to mind that could be the cause.

• The DB server connection needs changing to use HTTPS and a user name and password changed.
• ProCloud server needs a user name and password set up in the security model of EA.

To isolate the cause you could try disabling model security and see if its works in which case its likely to be 2) if it still fails. Otherwise it will be item 1)
More info on setting up can be found here
https://sparxsystems.com/enterprise_architect_user_guide/15.2/pro_cloud_server/cloud_server_client_add.html

[Modesto Vega]

Thank you, much appreciated.

If with

• The DB server connection needs changing to use HTTPS and a user name and password changed.

you mean that the model connection must have the "Require HTTPS and Authentication" enabled, it does.

I am confused about the part highlighted in red. My understanding, based on our experience, is that (if PCS, the database, and WebEA are hosted in different servers) the AD account running  the WebEA application pool must have read/write access to the the shared data repository/repositories. This worked well before enabling model security but enabling model security appears to have had an effect on it. Having said this, we have not included the AD account running the application pool in any Sparx EA group.

To isolate the cause you could try disabling model security and see if its works in which case its likely to be 2) if it still fails. Otherwise it will be item 1)

We will try this.

[Modesto Vega]

It is looking like this could boil down to WebEA not supporting/not supporting very well Windows/AD authentication.

All our Sparx EA users use their AD accounts to connect to a shared repository with model security enabled via PCS. This all works fine with PCS. However, with the same security model - i.e., AD user accounts and repository - this does not work with WebEA.

Is it possible to get WebEA to work using repositories with Model Security enabled and AD?

[ddrakos]

Hi,

maybe following webea configuration parameter could be of help

webea_config.ini

auto_login_windows_auth = "true"

Regards
Drakos
Modify message

[Modesto Vega]

Thanks Drakos, auto_login_windows_auth = "true" is set to "true".

We have an ongoing support case. In summary, this is what is happening,
1) WebEA works fine for models without model security with WebEA using HTTP to communicate with PCS.
2) For any model with model security enabled we are getting the following error "SSL certificate problem: unable to get local issuer certificate" instead of what is shown on step 5 of https://protect-eu.mimecast.com/s/r8eZCoVxqfOV3DYuObq1S?domain=sparxsystems.com. In this case, WebEA is using HTTPS to communicate with PCS.

According to https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_repository/webea_troubleshoot.html,

"This error suggests you are attempting an HTTPS connection without having SSL enabled"

and suggests that

"The webea_config.ini file does not include 'sscs_use_ssl = "true"' for this model; try adding this, then attempt to access the model again"

According to https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_repository/configure_webea_via_text.html sscs_use_ssl is no longer used after WebEA version 3.01.23.1690.

As of WebEA version 3.01.23.1690 (included in Pro Cloud Server 3.0.23) this option is no longer used. Instead WebEA determines this value dynamically based on the protocol in use.

This is all a bit confusing.

We are running PHP on IIS, the OS is Windows Server 2016.

[ddrakos]

Hi,

I had a similar error message with Apache / PHP where apache\bin\curl-ca-bundle.crt needed root PCS TLS certificate to be included at the end. Do you have same issues when using WebConfig php client?

So maybe you need to include PCS TLS host certificate into WebEA Windows keystore?

[Modesto Vega]

Thank you Drakos, the WebConfig php client works fine.

What do you mean with?

[SNIP]
So maybe you need to include PCS TLS host certificate into WebEA Windows keystore?

Also importing the PCS certificate into the Windows keystore of the server running WebEA? If so, we haven't tried this yet.

[ddrakos]

Just give it a try. How does your settings.php configuration look like? Are you using protocol = 'https'  and EnforceCerts ='true'  ?

[Modesto Vega]

Just give it a try. How does your settings.php configuration look like? Are you using protocol = 'https'  and EnforceCerts ='true'  ?

Will give it a try.

Isn't settings.php a Drupal file? We are running PHP on IIS and cannot find a setting.php file.

The WebEA repos are configured with protocol = HTTPS and Validate SSL Certificates = Yes.

[ddrakos]

This configuration is part of WebConfig PHP Client  <\WebConfig\settings.php>

[Modesto Vega]

We have imported the certificate to the PCS server into the WebEA server twice, one under Server Authentication and another under Client Authentication. The problem persists. The only thing we have not tried is importing the WebEA certificate on the PCS server.

The relevant section of our webea_config.ini file is below. I noticed 3 things:
1) the settings highlighted in red can only be set via Notepad (or any other text editor),
2) after adding the settings highlighted in red manually via Notepad, any attempt to use the config.php page to update the settings results on those settings been removed from the webea_config.ini file,
3) config.php always adds an access code, which in our case is the PCS admin password.

[model1 : settings]
sscs_protocol = "https"
sscs_server = "<server name>"
sscs_port = "443"
sscs_db_alias = "<model alias>"
sscs_access_code = ""
sscs_use_ssl = "true"
auth_code = ""
login_prompt = "true"
login_allow_blank_pwd = "false"
auto_login_windows_auth = "true"
default_main_layout = "list"
object_order = "3"
favorites_as_home = "false"
miniprops_navigates = "true"
navigate_to_diagram = "true"
show_search = "true"
recent_search_days = "30"
show_watchlist = "true"
show_browser = "true"
show_propertiesview = "true"
show_path_button = "true"
show_comments = "true"
show_chat = "true"
show_mail = "true"
show_discuss = "true"
add_discuss = "true"
participate_in_reviews = "true"
use_avatars = "true"
add_objects = "true"
edit_object_notes = "true"
add_objecttype_package = "true"
add_diagrams = "true"
add_objecttype_review = "true"
add_objecttype_actor = "true"
add_objecttype_change = "true"
add_objecttype_component = "true"
add_objecttype_feature = "true"
add_objecttype_issue = "true"
add_objecttype_node = "true"
add_objecttype_requirement = "true"
add_objecttype_task = "true"
add_objecttype_usecase = "true"
add_object_features = "true"
edit_objectfeature_tests = "true"
edit_objectfeature_resources = "true"
add_objectfeature_tests = "true"
add_objectfeature_resources = "true"
add_objectfeature_features = "true"
add_objectfeature_changes = "true"
add_objectfeature_documents = "true"
add_objectfeature_defects = "true"
add_objectfeature_issues = "true"
add_objectfeature_tasks = "true"
add_objectfeature_risks = "true"
prop_sec_location_visible = "true"
prop_sec_instances_visible = "true"
prop_sec_relationships_visible = "true"
prop_sec_taggedvalues_visible = "true"
prop_sec_testing_visible = "true"
prop_sec_resourcealloc_visible = "true"
prop_sec_attributes_visible = "true"
prop_sec_operations_visible = "true"
prop_sec_files_visible = "true"
prop_sec_runstates_visible = "true"
prop_sec_features_visible = "true"
prop_sec_changes_visible = "true"
prop_sec_documents_visible = "true"
prop_sec_defects_visible = "true"
prop_sec_issues_visible = "true"
prop_sec_tasks_visible = "true"
prop_sec_events_visible = "true"
prop_sec_decisions_visible = "true"
prop_sec_efforts_visible = "true"
prop_sec_risks_visible = "true"
prop_sec_metrics_visible = "true"
wl_period = "3"
cookie_retention = "180"
wl_recent_discuss = "true"
wl_recent_reviews = "true"
wl_recent_diagram = "true"
wl_recent_element = "true"
wl_resalloc_active = "true"
wl_resalloc_today = "true"
wl_resalloc_overdue = "true"
wl_test_recentpass = "true"
wl_test_recentfail = "true"
wl_test_recentdefer = "true"
wl_test_recentnotchk = "true"
wl_test_notrun = "true"
wl_feature_verified = "true"
wl_feature_requested = "true"
wl_feature_completed = "true"
wl_feature_new = "true"
wl_feature_incomplete = "true"
wl_change_verified = "true"
wl_change_requested = "true"
wl_change_completed = "true"
wl_change_new = "true"
wl_change_incomplete = "true"
wl_document_verified = "true"
wl_document_requested = "true"
wl_document_completed = "true"
wl_document_new = "true"
wl_document_incomplete = "true"
wl_defect_verified = "true"
wl_defect_requested = "true"
wl_defect_completed = "true"
wl_defect_new = "true"
wl_defect_incomplete = "true"
wl_issue_verified = "true"
wl_issue_requested = "true"
wl_issue_completed = "true"
wl_issue_new = "true"
wl_issue_incomplete = "true"
wl_task_verified = "true"
wl_task_requested = "true"
wl_task_completed = "true"
wl_task_new = "true"
wl_task_incomplete = "true"
wl_event_requested = "true"
wl_event_high = "true"
wl_event_incomplete = "true"
wl_decision_verified = "true"
wl_decision_requested = "true"
wl_decision_completed = "true"
wl_decision_new = "true"
wl_decision_incomplete = "true"

[Modesto Vega]

We made some progress here. The "SSL certificate problem: unable to get local issuer certificate" was a cURL 60 error. We resolved it by
1) extracting, as  Base-64 encoded X.509 (.CER), the intermediate certificate referenced by both the PCS and WebEA server certificates from the Windows certificate store, and
2) pointing ca.cainfo on php.ini to it

The next hurdle is that each time we supply valid credentials the WebEA server responds with a window requesting authentication again. By the way, this only happens with the model that has model/repo security enabled. The model/repo without model security enabled works fine.

[ddrakos]

Hi,

Good news. I suspect that your WebEA client is using cacert.pem as certificate storage because it is operating under IIS. For my case with Apache as WebServer /bin/curl-ca-bundle.crt is referenced as certificate storage. Anyway I believe that using self signed certificates have side effects. I have bumped into similar difficulties with customer on-prem certificates resulting into unknown certificate authority messages. Please tell me if you have certificate issues while using WebConfig client as well (HTTPS=TRUE).

[Modesto Vega]

[SNIP]
Please tell me if you have certificate issues while using WebConfig client as well (HTTPS=TRUE).

WebConfig over HTTPS has never given a problem. It has always worked, even before we made the changes outline below. This is what made this issue so annoying and difficult to troubleshoot.