Attending:

Etan Weintraub (chair)
Rob Carter (scribe)
Ethan A. Kromhout
Brian Arkills (chair)
Shilen Patel
Majeed Abu-Qulbain (scribe)
Jeffrey Crawford
Grant Hudgens
Warren Leung
Michael Trullinger
Jeremy Wilkerson
Chris Phillips
Chris Dalansky
Marcus Mizushima

Agenda:

1) Approval of last meeting’s notes for publication

2) Recap the high friction points we established last time

• • Anything we missed?
  • Anything we should drop as not high-enough friction?

3) Evaluation criteria for proposed solutions

• • What are the key details we need to collect?
  • What would make a solution recommended vs adequate vs not recommended?
  • Are there qualifiers which make a solution “fine” if present, but “insufficient” if not?
  • Does endorsement or use by another university matter?

4) Internal survey

• • What information do we need to know about each other?
  • Suggestions for questions which would facilitate our goals?

Notes:

Agenda item: Approval of last meeting’s notes for publication

• Brian: We need to approve the minutes from last time – any dissention?
• Rob: Anyone want to help with notes? (Majeed agreed)
• Jeffrey, Rob, Warren, and Etan Approved the notes
• The notes will be made public by Majeed

Agenda item: Recap the high friction points we established last time

Brian: gave a quick recap of the high friction points identified in the previous meeting

• • • multilateral federation
    • use of Azure MFA by other IDPs
    • business continuity, particularly when one IDP is cloud-based
    • disparate populations covered by different IDPs (campuses, campus vs. medical, alumni, etc.)
    • Agreement on protocols we'll cover (SAML, OIDC, OAuth for sure)
    • AuthNContextRef is a common issue that needs to be addressed (translation scenarios)
    • Token lifetime differences are significant and need to be addressed

Brian: few others at the end of the meeting

• • • Attribute Release
    • Consent

Majeed: Logout? I know for us at ISU log out has always been one of the most complicated pain points and it's always easier if you just say we're not gonna do log out. Maybe in a future world with passwordless, what does logout really going to get you. But It's definitely a friction point when integrating multiple SSO systems, in my opinion.

Etan: We had an issue come up last week that logout wasn't working anymore unless the user closes the browser -- we noted that our logout page explicitly tells people to do that for that reason. As long as I can remember, it's always been the fact that "logout" is actually an imaginary thing in SAML

Brian: When someone brings up logout in our team, folks just start laughing. It's a friction point maybe not high friction, but especially for token revocation scenarios where you need to invalidate active tokens that have been issued.  It's probably important to talk about in this linking SSO space.

Jeffery: I'm trying (but not having a lot of success) to push using force-authn as a way to avoid that sort of problem. It's not quite the same as logout, but it helps prevent a session from being remembered... I think if you want to force people to re-authenticate, you're probably best off using force-authn.

Etan: We direct people in that direction as well.

Brian: anything else we missed?

Brian: Is this a topic, then, that we need to explore and include a solution for?

Majeed: Just back on the protocols stuff -- should we include Microsoft-dependent protocols (WS-Trust in particular)?

Brian: It's a high-friction point, especially since a lot of device capabilities are blocked by Microsoft if you don't have it.

Michael: We have that same problem -- with InTune in particular.

Etan: Just out of curiosity, is there anyone else who's using WS-Trust who's heard that ADFS is going away from Microsoft?

Brian: They definitely want to get rid of it, but I've not heard anything about it being end of life -- it's clear, though that they've been trying to de-emphasize ADFS and pushing Azure. They have a new tool in preview now to help with migrating ADFS RPs over to Azure AD. When the principal PM of ADFS is promoting that tool, you know they're moving in that direction.

Etan: We retired ADFS a couple months back because of that push from Microsoft -- whatever requires WS-Trust is using Azure AD's implementation for that exclusively at JHU. We may be able to leave ADFS out.

Chris: (...brief introduction...) I co-wrote the ADFS Toolkit...  The story about ADFS lifecycle is that it's definitely on its way out. The Toolkit team expects it to have 5-10 years before it completely goes away though -- as fast as Microsoft wants to get rid of it aside, they're gonna be pushing for it to go away for a long time in order to get rid of it.  I'm not sure what taking it off our list means?

Etan: For me, it means it's not one of the primary technologies to focus on. Focus on WS-Trust in general, not so much on ADFS or Azure AD in specific -- focus on the protocols rather than the

implementations.

Brian: Chris's point is a good one, in that some of the solutions we'll have to consider will include ADFS -- one of the inTune solutions is to stick ADFS in front of Shib and federate ADFS to one

side and Shib to the other side -- you get WS-Trust and the device requirements met that way.  ADFS has to be in scope for us to that extent, but we don't have to focus on it except as a means to an end.

Etan: I'm saying ADFS should be more in the application list (like Shib) rather than in protocol list (WS-Trust is the protocol to consider).  You can do WS-Trust different ways.

Chris: Semantic alignment is where you seem to be heading...  I hear the word "solution", and looking at the charter... That's *how* to do it -- in terms of solution "patterns" -- is that where we're headed?

Majeed: Right -- we want to touch on common patterns, and provide recommendations about the different strategies -- what your ads and disads for each pattern are.  I can speak from experience as to how ordering Azure in front of or behind other things has different

behaviors.  If you link things together in specific ways, you'll get different results.

Chris: I have some material I can contribute -- in the CAF, we've been recommending some of these patterns, and I can share what we've been endorsing if the group is interested.

Brian: That sounds like it'd be great -- very valuable for what we're doing. In terms of our arc, starting to collate some of the solution patterns as possibilities we want to endorse and recommend is probably in our near future. 

Agenda item: Evaluation criteria for proposed solutions

Brian: Turning to the next agenda topic, we sort of need some sort of criteria for evaluating -- how we're going to figure out what to recommend and what to not recommend (or recommend against)...

Brian: Speaking of which, what are the key details we need to pay attention to and capture?

Majeed: Vendor road maps -- what's the expected lifecycle for such a thing? For a specific pattern, if you're linking multiple things together, there may be advantages or disadvantages attached to linking things in one order if one of the solutions is short-lived... Focusing user interaction on one of the SSO systems that's got a longer lifetime may have advantages

Majeed: We're going live with this very scenario -- AzureAD -> ADFS -> Shib tonight -- our view is that it isn't a permanent solution, but it'll solve some problems for us until Microsoft makes some changes to the global signon screen. Our issue was that we're not using SSPR, so we couldn't change that, but word from Microsoft is that we can expect to get what we need directly from the Microsoft solution in a few months...  We know some folks have built WS-Trust into Shib too, and that gives us a potential path out of ADFS...  I'm happy to hear the 5-10 year number from Chris, since it takes some of the rush out of getting rid of ADFS...

Chris: The timing from us is just the CAF expectation -- it's not from Microsoft per se, but the reason we hold that sentiment (here in Canada, and also in Sweden) is that we see 30-50% of IDPs in various federations being ADFS, and forklifting those is not going to be quick. Microsoft can choose, of course, to kill it suddenly, but they're probably not inclined to do that right now...  From a pragmatic point of view, any product you use will have the same issue -- support for anything can be dropped rather suddenly in any case, but realistically, we don't expect to see ADFS come out of the environment faster than that.

Etan: We actually had a Microsoft rep say ADFS was going away, and then backtrack because they weren't supposed to actually tell customers that. ADFS is included in Server 2019, so we at least have it until 2019 goes away (which should be 2029).

Chris: From that perspective, you can actually see it on the long-term support matrix from Microsoft -- they may not like it, and some folks may view it as outdated technology, but...

Etan: It gives us a sense that it's supported at *least* until then -- there is no official sunset, but it's clear Microsoft isn't making it their primary direction moving forward.

Brian: So -- vendor roadmap is definitely something to collect for every solution. Is cost something we should consider?  It's something I would consider for deploying a solution, but there are different types of costs...

Etan: I would maybe recommend whether it's "free" or "pay" -- everyone's institution is going to have a different perspective on whether a given cost is "high" or "low". Even Shibboleth, which you can get for free, you can also pay to join the Consortium.

Majeed: I try to avoid those financial discussions.

Warren: I think it's important to note what services have costs and what the cost structure is like (pay by user, pay by installation, so on)

Etan: +1 -- I like that idea a lot -- tracking which solutions cost how, not how much. It speaks to scaling factors.

Brian: Another thing I've done is a sort of small-medium-large thing - or how many thumbs up or down -- it's somewhat subjective, but you can kinda add in things like personnel costs. Some technologies take more or less time and people to support than others.

Majeed: Also skillsets required for a pattern -- what type of skillsets are needed?

Warren: That's a really valid point -- the IAM team usually runs the SAML stuff, but a windows team may be needed to operate ADFS, whereas that may not be necessary for things like Azure AD.

Majeed: Right. Not to take it back to licensing, but licensing doesn't just affect cost -- some things may have separate licensing features required for integration of things.

Chris: That may be important, actually. The kinds of things people are discussing in the field about IDP upgrades and changes come into play.  If I use something like Okta or AuthZero -- I pay X and i get Y and I don't have to worry about upgrades (myself) -- someone else does that for me. so it is a question of required FTE's .  I may have some material I can share about that (at least share in the session)

<Chris shared some material via screenshare: A spreadsheet with a list (rows) of IDP platforms with several columns representing various attributes of the coresponding IDP platform, status on support for certain features, expertise required to maintain, resouces required to run, and many other interesting information that helps the "Which one to run?" decision. >

Chris: This is a much older spreadhseet from CAF... Sorta half glancing at Brian's presentation from the first call, this is something similar...  In the CAF here in Canada, we get a lot of questions like "what's the minimal version of CAS that's OK to use with X?" or "Does app X support Y?"...  We try to characterize some of what we're talking about here now -- what the different software supports, what it requires, etc...  F5 is a good example -- I worked with a site that was running F5's SAML implementation with Shibboleth in front of it proxying to F5, and there were some very unique features and limitations

Chris: Institutions that choose one solution because of a single point problem they need to solve often find that that solution ends up not working in other use cases... We try to counsel people to identify the targets that are critical to the organization, not only now, but also in the future, and then try to tailor the solution you choose to that target.

Chris: Is this useful?

Etan: This looks like a great starting point for us -- if you can share the latest version with us, it'd be great. I'd want to add "does it support OAuth2/OIDC" -- other protocols apart from SAML and WS-Trust... we can extend this in those directions.

Chris: That's a great point -- just like the ADFS discussion, the platform is quite important, but the solution technique is probably even more so... It's as much about how you use the tools as it is about what tools you have in the toolchest.  The strategy and technique are the things to assess.

Brian: The spreadsheet columns are good, but the rows may need to change, since what we're going to be talking about are sets of products linked together in different ways.

Chris: So there's a line, for example, that would be Shib proxying to ADFS, rather than Shib or ADFS... And the answers in the columns would correlate with how that technique works (or doesn't work).  Note that some of those things are difficult to test -- unless someone in the group has actually used that strategy before, it may be hard to know if something does or doesn't work (but we can look for people who have that experience).

Etan: I was thinking where we might start with this document from the platform level, looking at what each platform supports, then have a separate sheet that points out what the different combined solutions cover. That way, people can identify when their problem can actually be solved without any linking, versus when a specific linking strategy may solve a particular problem. Sometimes decisions may depend on which solution(s) cover the greater or lesser part of a problem space.

Chris: The other things, just to note them... These kinds of things are near and dear to us in CAF as an operator...  If I were to characterize something as a rising concern it's sustainability -- how easy/hard/possible is it to stay current and contemporary with a given product? It's not just about whether it's supported -- it may be about how difficult it is to maintain and how rapidly it changes. The overall patching and update cadence has gotten intense. A given solution's TCO is conditioned not only by the initial cost but also by the maintenance cost.

Chris: We also, in CAF, think about what's operated on-prem versus what's operated as-a-service or operated (or possible to operate) in the cloud (IaaS style)...

Agenda Item: Internal survey

Brian: Before we run out of time, I want to catch up about the internal survey. Etan and I want to try and get an idea about what we're all running and what we've run before, so we know what we can find out from folks inside the room, as it were, and what we need to reach out to other folks to find out about. So we want to put together a survey of our membership. Love to hear about questions folks might want to see answered...

Michael: We've got 23 campuses with different degrees of expertise – some have CAS experience others don't, most have Shib experience, some have Okta and OIDC... How do you want to capture that (for a site with multiple campuses that may not be directly represented in the group)?

Etan (from chat): What SSO technology are you currently using? (Shib, OIDC< Azure, Google, CAS, etc.)? Do you have any solutions linked together? (yes/no), if yes, how are they put together? 

Etan: I think Rob's the only one in the room I really know at this level -- this is kinda a way for us to get to know each other and what we have expertise /experience with.

Etan: I think I might want to add questions about what technologies did you once use but have gotten rid or? What techs are you considering using in the future? Here at JHU, we're now running Azure AD as the login mechanism, and using Shibboleth as the IDP that actually talks to relying parties. I think that's the kind of information we want to get at with the survey. Specifics about what someone's knowledge bases are isn't quite as important -- I'm more interested in who's using what...

Michael: I'd probably try, then, to respond on behalf of the campuses that have other solutions in place. A lot of our challenges probably come from the way our campuses interact -- we essentially operate a federation for the California State system, as much as operate a solution for a single campus.

Majeed: Do you want information about the problems we're trying to solve (use cases)?

Brian: I think so yes.

Jeffrey: We're looking at SaaS solutions as a kind of new space – part of what we're hoping is that we can learn from the experience of others for cases where there's more than one entry point -- where some SaaS solutions and some on-prem solutions are mixed.

Etan: I'm up to 7 questions now, so... :-)

Chris: As an observation: The need to link SSO systems is usually driven by a need to get to something else -- something that isn't covered by a single existing solution. It may be a bit of a stretch to try and get a look at the services that need more than one technology -- what situation drives the decision to do linking?

Etan: I see what you're saying, but I'm not sure how to word it as a.. The scenario...

Brian: How about "What situation requires more than one IDP at your institution?"

Jeffrey: That's probably good -- our datacenter died one day and that led to the question of "what does it take to get SSO out of our datacenter?" It's more that than some specific application that drives the change...

Chris: That's a DR question, really -- the cloud isn't necessarily a natural solution to that problem :-).

Majeed: It feels like it comes back to either single platform or a combination down the left side with requirements fulfilled across the ..They might include DR or BC requirements, or they might be technical or user experience...

Etan: These are the questions I have so far:

• • what technology for SSO are currently in use (Shibboleth, OIDC, Azure, Google, CAS, others) in kind of a checkbox type list?
  • yes/no do you have it linked?
  • If yes, what is the order of linking?
  • What technologies have been sunsetted at your institution?
  • What technologies are you looking to add at your institution?
  • What technologies do you (person filling out survey) have knowledge of?
  • What pain points have you experienced in your implementations, if any?
  • What is the situation that requires more than one SSO solution at your institution?

[adjourned 3:00]