<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Location, Location, Location in Tech Talk</title>
    <link>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34678#M2571</link>
    <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/809125741"&gt;@Caute_cautim&lt;/a&gt;&amp;nbsp;wrote:&lt;P&gt;Interesting situation arose, shared client infrastructure using the same source IP address range.&amp;nbsp;&amp;nbsp; Salesforce Authentication uses SAML and XML messages, by default without MFA etc.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What happens if you have a business contract, which prevents users from seeing information from another organisation (insurance acquisition), but the original organisation is still in migration mode for months to come.&amp;nbsp; So one user from the organisation goes through to Salesforce, using the same IP address (shared infrastructure), and due to the current remote working situation (COVID-19) and they are forced to used BYOD to keep the business up and running.&lt;/P&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Source IP really should not be used as an authorization factor (e.g. to which organizational unit the user may access).&amp;nbsp; Instead, the SAML IdP (Identity Provider) should return said authorization in an attribute. This ensures that if an employee visits the other unit, their authorization remains consistent.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Now that we are all in the midst of work-from-home mandates, the use of source-IP as part of the IAAA process really shows its limitations.&amp;nbsp; It took my colleagues a few years of dealing with a mobile work force and mergers/acquisitions to come up with a few SAML strategies that seem work well for us:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;SPAN&gt;All aspects of authentication are done by our IdP.&amp;nbsp; For example, we would &lt;STRONG&gt;not&lt;/STRONG&gt; use Salesforce OTP or Salesforce geolocation.&amp;nbsp; Instead, our IdP handles those tasks internally (and consistently across all SPs - Service Providers).&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;FONT face="inherit"&gt;We use Geolocation to determine which authentication factors are required.&amp;nbsp; For example, if one is onsite, we accept NTLM or Username/Password.&amp;nbsp; When offsite, we add an OTP requirement.&amp;nbsp; We are contemplating adding a third factor when in countries where we have no business or when geolocation indicates improbable travel (e.g. over 1,235 km/h)&lt;/FONT&gt;&lt;FONT face="inherit"&gt;. However, we do not use GeoFencing to completely block access.&amp;nbsp; There are enough border cases and database errors that users need a way to react when it flares up.&lt;/FONT&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;Significant access roles (admin, manager, user, org unit, etc.) are best kept in corporate AD (or whatever you use for identity management) and handed off to the SP by attribute.&amp;nbsp; &amp;nbsp;This keeps your core security team in charge of the fundamental access decisions and more quickly able to modify/remove access.&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;App settings and preferences best remain with the SP.&amp;nbsp; Our general rule is that SAML only sends mandatory things via attribute.&amp;nbsp; For example, if the default should be "Compact View", the SP sets it initially and keeps track of the user's preference.&amp;nbsp; On the other hand, our IdP often sends "email address" because it needs to be "right" and users can not change it.&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;A href="https://help.salesforce.com/articleView?id=sso_jit_about.htm&amp;amp;type=5" target="_blank" rel="noopener"&gt;Just-in-time provisioning&lt;/A&gt;&lt;FONT face="inherit"&gt;&amp;nbsp;can be your friend, but you still need a sync process to handle deprovisioning.&lt;/FONT&gt;&lt;/LI&gt;&lt;LI&gt;&lt;FONT face="inherit"&gt;SAML becomes an easy "sell" when admins realize how simple it is to comply with account life-cycle management requirements (i.e. refer the auditors to the AD team).&lt;/FONT&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;SPAN&gt;Like most things, after one has a dozen or so SPs, it becomes more obvious where the line in the sand should be drawn between the IdP vs the SP.&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Sat, 11 Apr 2020 01:14:38 GMT</pubDate>
    <dc:creator>denbesten</dc:creator>
    <dc:date>2020-04-11T01:14:38Z</dc:date>
    <item>
      <title>Location, Location, Location</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34598#M2559</link>
      <description>&lt;P&gt;Attributed to The Cyber Security Hub on LinkedIn:&lt;span class="lia-inline-image-display-wrapper lia-image-align-center" image-alt="nerd-address.jpg" style="width: 340px;"&gt;&lt;img src="https://community.isc2.org/t5/image/serverpage/image-id/3993iDCB9A9A28809A39F/image-size/medium?v=v2&amp;amp;px=400" role="button" title="nerd-address.jpg" alt="nerd-address.jpg" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 09 Apr 2020 14:16:01 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34598#M2559</guid>
      <dc:creator>CraginS</dc:creator>
      <dc:date>2020-04-09T14:16:01Z</dc:date>
    </item>
    <item>
      <title>Re: Location, Location, Location</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34633#M2564</link>
      <description>&lt;P&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/780103681"&gt;@CraginS&lt;/a&gt;Would they have received the same response, if you were asked for your post box address?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Interesting situation arose, shared client infrastructure using the same source IP address range.&amp;nbsp;&amp;nbsp; Salesforce Authentication uses SAML and XML messages, by default without MFA etc.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What happens if you have a business contract, which prevents users from seeing information from another organisation (insurance acquisition), but the original organisation is still in migration mode for months to come.&amp;nbsp; So one user from the organisation goes through to Salesforce, using the same IP address (shared infrastructure), and due to the current remote working situation (COVID-19) and they are forced to used BYOD to keep the business up and running.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Interesting situation.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Caute_cautim&lt;/P&gt;</description>
      <pubDate>Fri, 10 Apr 2020 07:26:07 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34633#M2564</guid>
      <dc:creator>Caute_cautim</dc:creator>
      <dc:date>2020-04-10T07:26:07Z</dc:date>
    </item>
    <item>
      <title>Re: Location, Location, Location</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34678#M2571</link>
      <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/809125741"&gt;@Caute_cautim&lt;/a&gt;&amp;nbsp;wrote:&lt;P&gt;Interesting situation arose, shared client infrastructure using the same source IP address range.&amp;nbsp;&amp;nbsp; Salesforce Authentication uses SAML and XML messages, by default without MFA etc.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What happens if you have a business contract, which prevents users from seeing information from another organisation (insurance acquisition), but the original organisation is still in migration mode for months to come.&amp;nbsp; So one user from the organisation goes through to Salesforce, using the same IP address (shared infrastructure), and due to the current remote working situation (COVID-19) and they are forced to used BYOD to keep the business up and running.&lt;/P&gt;&lt;HR /&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Source IP really should not be used as an authorization factor (e.g. to which organizational unit the user may access).&amp;nbsp; Instead, the SAML IdP (Identity Provider) should return said authorization in an attribute. This ensures that if an employee visits the other unit, their authorization remains consistent.&amp;nbsp;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Now that we are all in the midst of work-from-home mandates, the use of source-IP as part of the IAAA process really shows its limitations.&amp;nbsp; It took my colleagues a few years of dealing with a mobile work force and mergers/acquisitions to come up with a few SAML strategies that seem work well for us:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;SPAN&gt;All aspects of authentication are done by our IdP.&amp;nbsp; For example, we would &lt;STRONG&gt;not&lt;/STRONG&gt; use Salesforce OTP or Salesforce geolocation.&amp;nbsp; Instead, our IdP handles those tasks internally (and consistently across all SPs - Service Providers).&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;FONT face="inherit"&gt;We use Geolocation to determine which authentication factors are required.&amp;nbsp; For example, if one is onsite, we accept NTLM or Username/Password.&amp;nbsp; When offsite, we add an OTP requirement.&amp;nbsp; We are contemplating adding a third factor when in countries where we have no business or when geolocation indicates improbable travel (e.g. over 1,235 km/h)&lt;/FONT&gt;&lt;FONT face="inherit"&gt;. However, we do not use GeoFencing to completely block access.&amp;nbsp; There are enough border cases and database errors that users need a way to react when it flares up.&lt;/FONT&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;Significant access roles (admin, manager, user, org unit, etc.) are best kept in corporate AD (or whatever you use for identity management) and handed off to the SP by attribute.&amp;nbsp; &amp;nbsp;This keeps your core security team in charge of the fundamental access decisions and more quickly able to modify/remove access.&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;App settings and preferences best remain with the SP.&amp;nbsp; Our general rule is that SAML only sends mandatory things via attribute.&amp;nbsp; For example, if the default should be "Compact View", the SP sets it initially and keeps track of the user's preference.&amp;nbsp; On the other hand, our IdP often sends "email address" because it needs to be "right" and users can not change it.&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;A href="https://help.salesforce.com/articleView?id=sso_jit_about.htm&amp;amp;type=5" target="_blank" rel="noopener"&gt;Just-in-time provisioning&lt;/A&gt;&lt;FONT face="inherit"&gt;&amp;nbsp;can be your friend, but you still need a sync process to handle deprovisioning.&lt;/FONT&gt;&lt;/LI&gt;&lt;LI&gt;&lt;FONT face="inherit"&gt;SAML becomes an easy "sell" when admins realize how simple it is to comply with account life-cycle management requirements (i.e. refer the auditors to the AD team).&lt;/FONT&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;SPAN&gt;Like most things, after one has a dozen or so SPs, it becomes more obvious where the line in the sand should be drawn between the IdP vs the SP.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Sat, 11 Apr 2020 01:14:38 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Location-Location-Location/m-p/34678#M2571</guid>
      <dc:creator>denbesten</dc:creator>
      <dc:date>2020-04-11T01:14:38Z</dc:date>
    </item>
  </channel>
</rss>

