[Openid-specs-fastfed] Meeting notes: Oct 3 / Sep 11 / Aug 28
Erik Gustavson
erikgustavson at google.com
Tue Oct 8 17:13:44 UTC 2019
Hi all,
I have not been diligent in sending meeting notes from the last few WG
sessions so I'm attaching them below.
Also, as a reminder, we'll continue with bi-weekly calls at 8am PT. You all
should have a meeting invite via the mailing list but, just in case, here
is the meeting info:
hangout: https://meet.google.com/wht-tipi-uoa
phone: +1 832-509-0551 PIN: 164 241#
Next 3 meetings are scheduled for: Oct 9*, Oct 23, Nov 6
best,
Erik
*We briefly discussed skipping Oct 9 but as the notes don't reflect a
consensus I'm still planning to host the meeting.
Oct 3, 2019 Attendees
Brian Rose, SailPoint
Darin McAdams, AWS
Dick Hardt
Erik Gustavson, Google
Chuck Mortimore, Salesforce
Matt Doemsch, SailPoint
Pamela Dingle, Microsoft
Prateek Mishra, ADP
Romain Lenglet, Google
Wesley Dunnington, Ping Identity
Big rocksRequired updates to the spec
No major changes are required at this point.
Minor nit: the ASCII art diagram at the beginning of the standard needs to
be updated.
We discussed the use case when an SP has multiple IdPs, e.g. a multi-tenant
application. FastFed supports this use case already. Each IdP needs to be
registered independently. The conclusion is that this is supported by the
spec, but we won’t specifically invest in it. We may provide guidance to
check tenant IDs carefully on both sides, to prevent spoofing.
There have been discussions about the relationship with OpenID Connect,
since both are addressing “federation.” FastFed is complementary.
Error handling may need to be better specified. Esp. each party needs to be
able to report errors back to the other party. Operations need to be
retry-able.
Support escalation contact information should be exchanged between RP and
IdP. Provider metadata would be the right place to include that
information. E.g. the email address of an admin, etc. like whois. That
information doesn’t need to be made available to tenants, it’s useful only
for SPs.
Ongoing SCIM 3 standardization is focusing on provisioning users into RPs.
We should look into it.
Dynamic client registration
We’re currently passing OAuth access tokens for SCIM during registration.
It would be overkill to require RPs to implement dynamic client
registration for SCIM. Dynamic client registration is out of scope for
SCIM, it’s irrelevant for SAML, and we don’t support OIDC yet.
How do we make sure that the JWT sent by the RP is really coming from the
RP registering RP? SCIM provisioning now uses a separate keyset from
authentication. The SCIM client follows RFC 7523 to get an OAuth access
token.
The RFC 7523 exchange needs to be explicitly documented, with examples.
HCM use case: RP-directed provisioning of users
Currently, FastFed supports provisioning from IdP to SP, but not the other
way around. This would be important for provisioning from an HCM (e.g. ADP)
into an IdP. Registering an HCM with an IdP is a rare event, and could be
done out of band without using FastFed. To determine whether this use case
needs to be supported in FastFed, everyone will evaluate how complicated
HCM registration is right now.
6 attributes are missing in SCIM core schemas for this use case, but this
is out of scope for FastFed.
What’s next after spec publication?Implementers' draft
We need to decide when to do the implementer’s draft. It seems like there
is more work to do on the spec before we do.
A percentage of votes from all OpenID members is required to pass. It’s
hard to get members to vote on a proposal they didn’t participate in.
Then we’ll need to give a presentation at the April 2020 board meeting to
vote. This requires registering in advance. Wes is on the OpenID board. He
and Microsoft could lobby the OpenID board.
Implementation timeline
AWS will try to have a production implementation by Identiverse in June
2020. Plan for Q1: all endpoints with scrappy UX. For Q2: better UX. Will
try to do an interop demo at Identiverse.
When do we need to align with Gartner? This is done by June 2020.
We discussed sharing integration tests in a shared GitHub repo.
SSO registration demo from SailPoint
Brian implemented an ActiveDirectory server frontend implementing FastFed
SSO as the IdP. WebFinger discovery is implemented using an S3 bucket.
Demo workflow:
1.
Sign into the SP.
2.
Setup SSO in the SP’s admin panel: click “Configure SSO using FastFed.”
3.
User is redirected to the ADFS server to login.
4.
SSO is setup.
The “finalize” exchange still needs more testing.
Next meeting
We’ll continue meeting over conf calls every 2 weeks.
We’ll schedule an in-person meeting the 2nd week of December 2019.
Tentative date: December 11th. The location is TBD (Bay Area or Seattle).
------------------------------
Sept 11, 2019
Attendees
Erik Gustavson, Darin McAdams, Adam Hampton, Austin Nicholas, Gokul
Baskaran, Wesley Dunnington, Dick Hardt, Matt Domsch
Agenda
1.
Discussion of Darin’s authentication proposal
2.
License Text
3.
What is outstanding on the draft?
Darin - authentication for SCIM etc. Darin described 3.3.3 and 6.6
Action item for all to review licensing text with their legal if they have
not done yet.
Matt provided feedback. Let’s get all feedback so we can integrate it all
into a next revision.
Erik: what is left?
Outstanding items in document:
-
How do we signal that we are actually done in handshake?
-
Discovery using Webfinger
-
Add in more specifics
-
Making sure there is clean separation between authentication and
provisioning
-
s/Identity Provider/XXX
-
Add in JIT provisioning
-
Ensure that SCIM is optional
Next Meeting
We will have another F2F during IIW prior to the WG meeting on Thursday.
Darin will suggest times.
Darin will represent FastFed at the OpenID Summit prior to IIW.
------------------------------
Aug 28, 2019
1.
Review AI’s from last time
2.
Open questions from Brian (Sailpoint)
3.
OAuth discussion
4.
Multi-app portfolios (i.e. Google, Microsoft, Atlassian)
5.
FastFed license
Attendees:
Brian Rose
Erik Gustavson
Darin McAdams
Matt Domsch
Romain Lenglet
Wesley Dunnington
Austin Nicholas
Chuck Mortimore
Dick Hardt
Outstanding AIs (see below for status)
Brian: How does the SP know when the IdP is completed?
Darin: Scenario 1: If user is admin for SP and IdP, they finish the
experience on the IdP. IdP can communicate that process has failed.
Scenario 2: Separate admin for SP and IdP. Process starts by SP Admin.
Process completed by IdP Admin at some point later. The IdP Admin sees the
failure. IdP then magically notifies the SP admin that setup is complete.
Objective is to push complexity onto IdP rather than SP.
Erik:What if the SP admin leaves companies? Is there some way for the SP to
poll to get status of completion?
Brian: Can SP optionally get some way to check the status?
Dick: what happens?
Brian: No. How does the SP know that the IdP got back what it needed and
was successful.
Darin: I was not comfortable with the synchronous nature of last step.
Dick: Add an ack
Austin: our SP won’t be ready to go for 5 minutes
Dick: SP can respond saying “not quite ready, check back in 5”
Eric: let’s add this into the flow
Darin: ok!
Eric: thanks for helping find issues
Brian: I think this deals with my issue
Erik: Atlassian had set up a suite of applications that is setup as a
single application at Google. Atlassian lets users start at SP and initiate
from the specific SP. SPs that have a suite sort it out at their side. They
are more sophisticated.
Darin: FastFed license. How to get a license to use icons in FastFed.
Please check with your legal to see if you have an issue with the license.
https://bitbucket.org/openid/fastfed/src/master/license/FastFedLicense-1.0.txt
Darin: How will the SP get a client ID and secret
Erik: Does not seem like the SP has a long lived access token.
General discussion: the protocol has been symmetric, so useful for SP to be
a client
Darin: how does SCIM work today for getting credentials
Mauna: we do a pre-registration with client ID / secret or use a long lived
bearer token. We will do whatever the SP wants.
Darin: let’s standardize
Chuck: we support asymmetric keys, rarely used. Passing a long lived access
token may break existing code.
(Dick did not take much notes here)
Darin: I have enough feedback to think about this
Erik: cadence? Every 2 weeks
-----------
Last Meeting Notes
Attendees
- Chuck Mortimer, Salesforce
- Darin McAdams, AWS
- Erik Gustavson, Google
- Jacob Frederick, AWS
- Junfeng Wu, Cisco
- Matt Domsch, SailPoint
- Pamela Ding, Microsoft
- Rafael Kabesa, Salesforce
- Rob Otto, Ping
- Romain Lenglet, Google
- Sanjoli Ahuja, ADP
- Wesley Dunnington, Ping
1. Feedback / questions from the demo at Identiverse
- How can I control who can access this app?
- Will Ping Federate support FastFed?
- FastFed addresses a real problem. It will eliminate lots of manual work.
- Got some questions about protocol details.
2. Draft updates
Darin needs to incorporate the feedback notes from the last WG meeting.
Matt requested that the standard supports using a source other than an IdP
for user provisioning.
Updating a federation is not (yet) covered by the standard, e.g.
- Enabling provisioning after the fact.
- Update provider metadata.
- Turnoff (already discussed in the last session).
Even if we don't address that now, we should clarify the scope of the
standard, e.g. in a FAQ document.
Sailpoint and ADP determined the minimum set of attributes needed for HR
extensions, when provisioning from an HRIS to an IdP.
Matt will share with the WG.
3. FastFed adoption
Ping is interested in joining the WG.
It is not easy to get started working on FastFed.
We need a better website front page.
Jacob has sequence diagrams that would be useful for such docs.
There is currently no "security considerations" section in the spec.
We need to get security experts to review the spec. Google and ADT will get
resources.
We need to get more "pure" service providers involved to get feedback on
the usability of the protocol.
We need more specific guidance to implement FastFed.
In the long-term, integrating with frameworks (Spring, etc.) will help
adoption.
We need a test harness to help developers.
Ideally, it would be good to have a reference implementation / mock
endpoints.
Both the Google and AWS implementations of the SP and IdP endpoints for the
Identiverse demo were developed with that purpose in mind.
Google and AWS will open-source those as reference implementations.
4. Timeline
We'll have to clarify early whether implementers (Google, AWS, etc.) will
do any branding around FastFed.
To get broader adoption, we need bigger and more frequent meetings.
We decided to schedule meetings once per month.
We should advertise the meeting calendar on the website to get more
attendees.
Erik and Adam aim for an implementers' draft by Aug 2019.
The last review of the draft will be at IIW in Oct 2019.
We'll also try to do interop testing at IIW.
How to bootstrap adoption?
We will need a critical mass of IdPs (Google, Ping, Okta) and trailblazing
SPs.
Then we can focus on advertising the standard to a broader SP audience.
5. Action items
- [Jacob, Erik] Write up a FastFed introduction for the website's front
page. (not done)
- [Pamela] Give Erik access to edit the website. (Nat got everyone access)
- [Pamela] Get everyone signed up on the mailing list. (seems like that is
the case)
- [Erik, Sanjoli] Get Google and ADT to do a security review. (outstanding)
- [Matt] Share the set of attributes for HR extensions. ?
- [Erik, Romain, Jacob] Look into the processes to open-source the demo
implementations, esp. determine the timelines. (not done)
- [Erik] Schedule the next meeting. (done!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191008/aca2155e/attachment-0001.html>
More information about the Openid-specs-fastfed
mailing list