IDEA
|
Azure AD is now refreshing certification every 3 years, but it can be refreshed more often (more secure). Please introduce certificate autorenewal for SAML and OpenID connect, to prevent outage. https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/manage-certificates-for-federated-single-sign-on
... View more
02-01-2022
02:19 AM
|
0
|
0
|
1232
|
POST
|
Thanks for pointing me to the WebSocketContextURL. I already make use of the WebContextURL for Server and Portal. So I know where to set it. This setting is not mentioned in documentation at Reverseproxy, but it is mentioned in the Server Admin API properties. Now have to find out how the ReverseProxy is handling streaming data.
... View more
05-14-2019
03:07 AM
|
0
|
0
|
563
|
POST
|
I have GeoEvent behind a reverseproxy to do port translation between 6143 and 443. This works fine for the REST interface: https://geoevent.domain.com/geoevent/rest However, when going to https://geoevent.domain.com/geoevent/manager/ it redirects the page itself to 6143 ,which is forbidden at our network environment for public use. How to configure Geoevent Manager behind a reverseproxy (or a Webadaptor if that works too)?
... View more
05-13-2019
07:48 AM
|
0
|
1
|
868
|
POST
|
Question about the deployment of GeoEvent Streamingservices in a Enterprise basedeployment setup. I want to expose streamingservices in the Enterpriseportal, secured. This must be on the standard https port 443. In all samples, I see the streamingservices are items in Portal, listed with the REST endpoint of the Server with GeoEvent (ArcGIS Server). First response of the rest endpoint contains the reference to the WS:// with the geoeventserver:6143 url. So for me it should be: https://portalurl.domain.com/portalWA/home https://arcgisurl.domain.com/arcgisWA/rest/ and wss://geoeventurl.domain.com/geoevent/ I already have the https://geoevent.domain.com/geoevent/ behind a reverse proxy, to do porttranslations between 443 and the 6143. However, I cannot find the right deployment documentation for this streamingservices scenario.
... View more
05-13-2019
07:45 AM
|
0
|
2
|
775
|
IDEA
|
SAML Metadata Within the SAML protocol, metadata, including certficates, must be refreshed. Metadata/Certificates have a specific end date, and at some point with security incidents, metadata/certificates may be revoked and replaced. With the current version of Portal (and ArcGIS Online), this metadata must be refreshed manually, by uploading the metadata xml. Benefits The SAML protocol has a feature to have auto-renewal of this metadata. We want this to be implemented in the ArcGIS Portal (including ArcGIS Online). Benefits are: - No manual interaction when certificate is renewed on shedule - No outage when on incidents the certificate is revoked and renewed on an earlier unplanned time - No outage, downtime window, when manual renewing: when manual renewing, you can only have 1 certificate active, where auto renewal has overlapping 2 certificate period Deadline At our organisation this auto-renewal is implemented and followed by 90% of the applications that are connected. We as GIS departement are handicapped with the manual refresh. IT-security department has given us the deadline for end of 2019 to implement this. Since it is part of the standard portal functionallity I have to ask Esri to implement this. Metadata auto-renewal information The IDP token singing certificate is an important part of the security within the SAML protocol. In the our scenario the signing certificate expires each 2 years. The signing certificate is automatically renewed by the IDP upon it’s expire date. The IDP automatically updates his metadata upon this so the new certificate is reflected in the metadata. However, this certificate renewal will cause the trust between the SP and IDP to break, until the SP administrator (manually) imports the new IDP metadata. To prevent outage of SSO to an SP, auto-renewal can be used to periodically (daily) check the metadata url for changes and automatically import the new metadata file towards the SP if a change is detected.
... View more
02-01-2019
01:55 AM
|
15
|
3
|
2163
|
IDEA
|
SAML Metadata Within the SAML protocol, metadata, including certficates, must be refreshed. Metadata/Certificates have a specific end date, and at some point with security incidents, metadata/certificates may be revoked and replaced. With the current version of Portal (and ArcGIS Online), this metadata must be refreshed manually, by uploading the metadata xml. Benefits The SAML protocol has a feature to have auto-renewal of this metadata. We want this to be implemented in the ArcGIS Portal (including ArcGIS Online). Benefits are: - No manual interaction when certificate is renewed on shedule - No outage when on incidents the certificate is revoked and renewed on an earlier unplanned time - No outage, downtime window, when manual renewing: when manual renewing, you can only have 1 certificate active, where auto renewal has overlapping 2 certificate period Deadline At our organisation this auto-renewal is implemented and followed by 90% of the applications that are connected. We as GIS departement are handicapped with the manual refresh. IT-security department has given us the deadline for end of 2019 to implement this. Since it is part of the standard portal functionallity I have to ask Esri to implement this. Metadata auto-renewal information The IDP token singing certificate is an important part of the security within the SAML protocol. In the our scenario the signing certificate expires each 2 years. The signing certificate is automatically renewed by the IDP upon it’s expire date. The IDP automatically updates his metadata upon this so the new certificate is reflected in the metadata. However, this certificate renewal will cause the trust between the SP and IDP to break, until the SP administrator (manually) imports the new IDP metadata. To prevent outage of SSO to an SP, auto-renewal can be used to periodically (daily) check the metadata url for changes and automatically import the new metadata file towards the SP if a change is detected.
... View more
02-01-2019
01:55 AM
|
7
|
0
|
651
|
IDEA
|
Above examples include groups. It must also include roles/licenses (lvl1/lvl2 with the new names for Creator, Fieldworker etc..) and the special licenses (arcgis pro, navigator, etc..)
... View more
11-20-2018
03:54 AM
|
1
|
0
|
1594
|
IDEA
|
We need a Access Management interface, based on SCIM v2 for separating the Identity en the Access management layers. Portal has already support for the standards for Single Sign On: SAML. This is for Identity management (authentication). Our security standards require to separate the Access management (authorization). THis is company wide implemented via the SCIM interface. All applications within our company are now required to have a SAML and a SCIM interface. My request/idea is to implement this SCIM interface to Portal. Basic workflow when working with SAML + SCIM: User is registered in Portal using his company Identity Portal can verify login using the trusted SAML interface between portal and the OpenID/ADFS server using SAML This way user can log in using Company Identity Groups are created in Portal Groups are synced with Accessmanagement (IAM) using SCIM Groups are filled with the authorized Identities within IAM Filled Groups are synced with Portal Logged in user can access the authorized groups. 1 - 4 are now in place. 5 -7 have to be implemented using new SCIM v2 interface. SCIM v2 is an open standard, and worldwide. System for Cross-domain Identity Management - Wikipedia SCIM: System for Cross-domain Identity Management
... View more
11-15-2018
08:09 AM
|
20
|
9
|
2014
|
Title | Kudos | Posted |
---|---|---|
7 | 02-01-2019 01:55 AM | |
15 | 02-01-2019 01:55 AM | |
1 | 11-20-2018 03:54 AM | |
20 | 11-15-2018 08:09 AM |
Online Status |
Offline
|
Date Last Visited |
02-01-2022
04:00 AM
|