IAM/IRM CONSIDERATIONS FOR SAAS PROVIDER SELECTION
•Download as PPTX, PDF•
2 likes•1,028 views
This document discusses important identity and access management (IAM) considerations for selecting a software-as-a-service (SaaS) provider. It outlines key questions to ask the SaaS provider regarding support for single sign-on protocols, ease of provisioning and de-provisioning users, whether their technical environment fits the organization's constraints, and ability to test integration before going live. The document also covers identity lifecycle management standards like SCIM and questions for IAM experts on how federation can be made easier.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to IAM/IRM CONSIDERATIONS FOR SAAS PROVIDER SELECTION
Similar to IAM/IRM CONSIDERATIONS FOR SAAS PROVIDER SELECTION (20)
More from ForgeRock
More from ForgeRock (20)
Recently uploaded
Recently uploaded (20)
IAM/IRM CONSIDERATIONS FOR SAAS PROVIDER SELECTION
- 1. IAM/IRM considerations for SaaS provider selection David Taylor (Smart421) Cliff Dobbs (ARM)
- 2. What & Why Who for: Project managers & Business Analysts Architects Mainly companies using SaaS providers What: Connecting your company’s IAM infrastructure to that of a SaaS provider Why:
- 3. Questions for “them – the SaaS provider”: 1. Does their service support an open SSO federation protocol? 2. How easy is it to automate the provisioning and de-provisioning of users? 3. Does their technical environment fit with your constraints? 4. Can the integration be tested before go-live? 5. What about mobile access? And for “us”: 1. Do you understand your own requirements? 2. What can we do to make federation easier? 3. Can IDaaS vendors help with this?
- 4. Questions for the SaaS providers
- 5. Does their service support an open federation protocol?
- 6. Does their service support an open federation protocol? You: AP / IdP SaaS Vendor: RP / SP 1: Visit Resource (no session) 2: Authenticate user 3: Generate Fed. Assertion 4: Validate Assertion 5: Create Session & allow access
- 7. Does their service support an open federation protocol? You: AP / IdP SaaS Vendor: RP / SP 3: Generate Fed. Assertion Protocol 4: Validate Assertion 5: Create Session & allow access Profile Assurance
- 8. Does their service support an open federation protocol? Which Federation Protocols? ‘Proper’ Identity Federation protocols Shibboleth SAML 1.x WS-Fed SAML 2.0 OpenID OpenID Connect Pseudo Identity Federation Protocols OAuth OAuth 2.0 OATH
- 9. Does their service support an open federation protocol? Which Federation Protocols? ‘Proper’ Identity Federation protocols Shibboleth SAML 1.x WS-Fed SAML 2.0 OpenID OpenID Connect Pseudo Identity Federation Protocols OAuth OAuth 2.0 (but OK for authorization scenarios) OATH
- 10. Does their service support an open federation pWrhoictho Fceodel?ration Protocols? SAML 2.0 Protocols
- 11. Do you understand your own requirements? What technical constraints do you have? What user journey requirements do you have? What security policy requirements do you have? What audit requirements around provisioning?
- 12. Does their technical environment fit with your constraints? IdP SP Ms Mobile IdP My.Com MyCloudCRM SSO ACS Artefact
- 13. Does their technical environment fit with your constraints? 2FA IdP SP Ms Mobile IdP SSO My.Com MyCloudCRM SSO ACS Artefact
- 14. Does their technical environment fit with your constraints? IdP SP IdP SSO My.Com SSO ACS MyCloudCRM Cusdtomer / Partner 2FA? IdP
- 15. Does their technical environment fit with your constraints? 2FA IdP SP IdP Proxy IdP My.Com SSO ACS MyCloudCRM Cusdtomer / Partner IdP Ms Mobile SP IdP 2FA?
- 16. Does their technical environment fit with your constraints? IdP SP IdP Proxy IdP SP IdP My.Com SSO ACS MyCloudCRM 2FAX
- 17. How easy is it to automate the provisioning and de-provisioning of users? Identity Lifecycle Management None / Implicit / Dynamic Flat file exchange (usually proprietary) LDIF exchange - > Directory Synchronisation SAML 2.0 explicit support SCIM Frequency, Latency… how fast does SaaS provider need to react to changes? Transactional integrity / Audit …. I thought we turned off Johnny’s access SCIM Resource Model, with thanks to http://www.simplecloud.info
- 18. Can the integration be tested before go-live?
- 19. Questions for the IAM experts
- 20. What should we be asking the SaaS providers to do? Play nicely together … … like the ARM Connected Community does
- 21. Can IDaaS vendors help with this?
- 22. What can we do to make federation easier?
- 23. Summary – What does good look like? SaaS vendor supports a good ID Federation protocol – fit to constraints Solution can be tried out in a non-live situation Provisioning and de-provisioning is painless – audit / assurance of events Mobile application security mechanisms are appropriate
Editor's Notes
- [Both – 1 min] Breif intros
- [David] SaaS provider examples: Salesforce, Expenses system, Yammer. Why: SaaS consumers to help success of project SaaS providers to differentiate themselves Given the 20 minute slot, this is going to be done as an Agile presentation: - the slides can be considered as user story cards. They’re not the answer, but a promise to have a conversation.
- [Cliff] I jokingly present a “them and us” situation, here, and I do feel that that is where we are at. But, I don’t believe it needs to be that way. ARM owes its success, somewhat, to the partnership business model that underpins how we operate. I do believe that it is possible for the SaaS providers and the IAM industry to work together for everyone’s benefit.
- [Cliff] Any Star Trek fans here? – Sorry, silly question I don’t think I need to belabour the benefit of open protocols at a ForgeRock event, but you may have to when trying to convince your business partners that this really is a show stopper; Some notes on why open protocols are a “good thing”
- [David] Going back from the end goal… The points of interest are. (next slides)
- [David] Going back from the end goal… The points of interest are. Protocol, what protocol, what information, what mapping: bells & whistles. Profile: Does it need to be created at the SaaS end up front, how will it be deactivated Assurance: What info does the SaaS provider use to provide on-going access to an application (web session timeout… , Mobile – oath token longevity)
- [David] Vendor tooling support is an issue. For the choice of protocol, the things to look for are: Identity vs. Authorization protocol Future of protocol (vendor, other SaaS provider support) Completeness Browser and firewall friendliness Shibbloleth… mainly used in Uni’s Now also feeding in to SAML 2 SAML 1.x …. Yes, but unloved, superseded by SAML 2 WS-Fed …. Yes, but not well understood (e.g. WS-FED is a wrapper on SAML 1.x protocols), superseded by SAML 2.x SAML 2.0 is stable, has acceptance, and will deal with Identity life-cycle events – basically you can provision & de-provision via SAML (but support of some those features inconsistent) OAuth is a authorization protocol, not authentication. See valet key analogy OpenID -> Oauth -> OpenID Connect OATH – Reference Architecture for strong Authentication, Open Spec. for OTP solutions
- [David] Bottom line is: Right now SAML 2.0 A good Future bet is OpenID connect. ForgeRock support it now, and Google, Twitter and so forth are talking about it [DT – check]
- [David] Remember this ? Even if SAML 2.0 refreshes the parts that other protocols can’t reach, you need to consider…: Session time-outs Universal SLO including at IdP / Asserting Party Browser Artefact v.s. POST profile (Artefact is re-direct friendly, POST profile has SP-initiated vs. IdP-Initiated vs. Simple re-direct to IdP-initiated Request / Response parts signing & encryption Metadata Exchange In consideration of both user journey, protocol support at each end (e.g. not all vendors support SP-initiated), and
- [Cliff] Network security, including firelwalls and WAF. User journey: Single sign-on, SLO, SP vs. IdP Policy for SSO: e.g. Adaptive authentication
- [Cliff] [Cliff: we may need to really shorten this to do you have any further environmental constraints? - Network security policy - User authentication outside network. The slides could easily take 10 mins on their own. This is as much a policy problem as it is a technology problem. For example, ARM does not allow ANY unauthenticated traffic in through the firewalls. This prevents the use of SAML’s HTTP Artefact Binding and rules out certain providers. It also prevents us from deploying an OpenAM DAS in our DMZ. Scenario 1 – Artefact binding If the SP only supports artefact binding, does your environment support it. Scenario 2 – Mobile users If your SSO environment is not accessible from the web, how do mobile users authN? Is VPN an acceptable compromise in you organisation? Do you even need mobile users to access this particular service? If you do, does the SP have a mobile app? More on mobile apps later
- [Cliff] If you can deploy something into your DMZ How does the SP handle having two IdPs? If your DMZ IdP has to be configured to use 2FA, how does the SP handle different AuthnContextClasses. Can your firewall policy allow the SP to use artefact binding?
- [Cliff] Scenario 3 – Customer / Partner access to the SP Do you need to share access to you SP with partners, customers or suppliers? Can your SP work with multiple IdPs? Are you able to, or do you want to impose 2FA on the customer/partner? What controls do you need to apply to third-party users
- [Cliff] Could an IdP Proxy help in any way? By adding a layer of separation between you and your SP By understanding the difference between customer and employee (e.g. john@mycom.com vs john@partner.com) By providing a single IdP for SPs to use
- [Cliff] [Is this the same as the IDaaS provider scenario] Could an IdP Proxy help in any way? Can the IdP proxy differentiate between internet users and internal users? Assuming SP initiated; But what about Mr Internal-User? He shouldn’t need to use 2FA. Can the IdP proxy accept an assertion from the internal IdP? Can your internal DNS spoof the IdP proxy FQDN? Assuming IdP initiated; Can both your IdP and the IdP proxy be configured to present an assertion in the same format? The variations seem to be endless. Be sure you understand yours.
- [David] E.g. use of SCIM or directory sync rather than the SFTP and import of CSV files Arguably, the de-provisioning piece is the more important. More and more SaaS providers are expecting us to use some kind of directory sync tool to keep our identities in sync with their service. As we sign up to more services, do we really want to be installing and maintaining DirSync tools for each and every service provider? What we really want is an open protocol (SCIM?) and a single tool that is able to support multiple configurations to different providers. This, however, becomes tricky when dealing with data that is not typically stored in AD or OpenDJ; like travel authorisation. That’s when we find ourselves falling back on file uploads. File uploads are a problem. This is potentially “personal” information being transmitted and it needs to be stored and transmitted securely. If file upload is the only option, then we need to be aware of how frequently the upload takes place and what your company’s “Risk Appetite” is. If this is not a very frequent upload, and the impact on your business of the loss of the information available through this service is high, then there needs to be a means by which an administrator can quickly and easily remove access from individuals as and when they leave your company.
- [David] You don’t want to lock out everyone from your service, especially not yourselves. So, is a soft-rollout supported? Or better still, a full test environment. This is depressingly inconsistent: From full dev, test and production environments to everything is “live” If the SaaS provider is not able to supply a test environment, make sure you have a guaranteed support contact on call in the event things don’t work and you need to do a rapid back-out. Oh, have a back-out plan
- [Cliff] Not all SaaS providers have great answers to the above questions. This should also provide a guide for prospective SaaS providers wishing to lower the barriers to using their service. Play Nicely Together, like the ARM Connected Community does. Wouldn’t that be nice? For the SaaS industry to come together and agree on a set of standards and then adhere to them. Stop developing proprietary Directory Sync tools It really is not scalable and we’re not going to put all of our eggs in your basket Adopt open standards for provisioning and de-provisioning Give us the chance to have a single place to configure all of our SaaS provisioning Stop using CSV files uploaded via HTTPS or SFTP Again, this is not scalable Use open standards for authN and authZ SAML, OpenID Connect Use open standards for mobile apps OAuth2, Certificates. Please, please provide us with test environments And the ability to configure them ourselves Name check: ServiceNow have almost got it right. I was able to configure the SSO myself There is a “side door” to bypass SSO if things go awry Their debug logging was very good To be honest, I think the only way we are going to get the SaaS providers to change is to tell them that this is why we’re not using them. But first, we need to convince our business partners that this is the right thing to do.
- [Cliff] Until we can get to a situation where all SaaS providers adhere to open standards like SCIM we may need intermediaries to help us manage our cloud identities and their access rights. But there are gaps? As already mentioned, there are attributes that may not be stored in your corporate directory. Simple DirSync tools will not help us if we are asking the IDaaS vendors to provision people into applications that need data like authorising manager, pay grade or start & end dates. ========================== What is IDaaS - Global self-serve identity, with affiliation to companies (e.g. M$ Passport) - currently vaporware ??, but government identity assurance programmes, e.g. HMRC - public persona vs. private vs. MyTerrorism login - Bits of IAM capability, e.g. Google authenticator - IAM plumbing as a service. (most common in cloud above) IAM Plumbing vendors Pros: lower barriers to entry in time & cost for low # of users. can lower complexity by providing IdP proxy – requires only one integration & all further integrations handled by vendor Cons: Typically use deep integration to corp (dir sync.) Differentiated SSO policy for on premise & off-premise Still need to address / vet End SaaS vendor handling (timeliness, audit, transactional integrity) of IDLM events Security considerations w.r.t. Mobile apps If you are concerned about IDLM handling at all, you first need to satisfy yourself that your cloud vendor has a good story on this. AUDIT! How can you be sure the IDaaS has de-provisioned your user? How can you be sure the SP has de-provisioned your user?
- [Cliff] Unify your identities Even if you can’t actually get rid of the multitude of identity stores, have a single, homogenised source of people data Standardise your people data It’s much easier producing exports of people data for SaaS providers when it all conforms to a set of well defined standards Know your company’s Risk Appetite and how it pertains to this service. If the information available through this service is not particularly confidential, it may not be an issue if users are not de-provisioned straight away Have a rigorous identity lifecycle management process There’s not much point in demanding of our SaaS providers that they support good practice, if we don’t ourselves. Roles. Are the people provisioned the right people? If you are paying per user, you don’t want to be paying for those who don’t need access.