C-DAD Cross-Domain Application Deployment “simple federation” (for enterprise apps)
C-DAD: Cross Domain Application Deployment
Tuesday 2G Convener: Dick Hardt
Notes-taker(s): Ritwick Dhar
Tags for the session - technology discussed/ideas considered:
How to simplify/automate SaaS app registration and setup with IdPs
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Sample problem statement: How do app developers using Google as IdP set up AWS (as a SaaS app) without creating brand new identities in AWS, without cutting and pasting data. Define pattern for optimizing setup.
Proposed pattern:
Step 0: App registered at the IdP (bootstrap flow) - one time - (using metadata containing endpoint for discovery….)
Step 1: Admin authenticates at IdP (Google)
Step 2: Select app (AWS)
Step 3: Answer questions - what questions? - Optional
Step 4: Get redirected to magic entry point for app
Step 5: Authn @ app [OR create account] - should be OOB.
Step 6: Answer Qs
Step 7: redirect to IdP
Step 8: Tests and checks
Discussion:
Step 0: Can app ask IdP for attributes that the Idp does not want to give (phone numbers, etc)
Paul Madsen: The smarter Step 0 is, easier the other steps are? 0 informs 3 and 6… driving the UI
Shashank: Make the process smart …. collapse rest of the steps? We are not there yet - Salesforce has a good example of this.
Rachit: Can #2 be ‘paste a URL, and discover App’: App publishes URL? Dick: where did the URL come from?
Prateek: Step 0: describes identity requirements that surrounds the app, there’s no such manifest today. That’s foundational.
John Bradley: Q. on scope: Is provisioning included? Are there 3 parties here instead of 3?
Enterprise dir. may not be run by the same identity as the IdP?
The vision is:
SAML/OIDC for authentication
SCIM for provisioning
Auth for SCIM is one the things we need to set up in the steps
Paul: #5 implies admin already has an account at SaaS. We shouldn’t mandate an existing pwd for the SaaS. [Q]
Where does user choose app name?
Does the service push the data, or does the admin?
0: Admin can be aware of the URL….
In many cases, users can become aware of the app as they are using it.
Shadow IT: user sets up their own identifier into the SaaS app.
We need to figure out Step 0, 3, 6
What going on with the redirects: 4 and 7 (oauth-type flow)
The account that manages federation, should that be out of band authentication?
- break glass. No one can authenticate any more…. how do you fix it?
- say you want to change who your IdP is.
- Logging in locally at the SaaS app.
Best practices for this?
1, 5: Should use MFA.
5 - federating into an app doesn’t preclude app again MFA. Most industry best practices usually avoid managing federation with federated identities. This is an OR operation: either use existing OR create an account. If they’re not authenticating with the same IdP, doesn’t the shadow IT still exist?
No, because shadow IT is completely independent. Assumption is that SCIM will deprovision admin… maybe we need a ‘super-admin’ role.
Above has to do with ‘how do we deal with privileged accounts’ - out of scope for this discussion.
SCIM could become pervasive. As we are branching out to SaaS, central directories are not possible any more. Back channel push @ change.
Discussion about where this belongs? OAuth? IETF?
Spin up an email list? That’s the quickest. Let the ADs worry about where it goes.
Concern: OAUTH working group is going through a consolidation phase. Rechartering. May be out of scope.
Should it be OIDF? Probably is the best place? OIDF could possibly agree
Other option: Like SCIM, do it completely offsite.
Outstanding questions & observations:
Need to define Steps 0, 3 and 6 better. Step 0 is critical. Can collapse a large part of the flow.
Step 8: Each SaaS app could have a test account that the IdP can to check continuously (first as part of 8 and then over time).
Action Items:
John Bradley - will talk to Steven (Area director) about creating an email list
