Attending:

Etan Weintraub (chair)
Rob Carter (scribe)
Brian Arkills (chair)
Shilen Patel
Majeed Abu-Qulbain (co-scribe)
Jeffrey Crawford
Michael Trullinger
Jeremy Wilkerson
Chris Dalansky
Marcus Mizushima
Ryan Rumbaugh
Erik Coleman
Paul Riddle

Notes:

Brian: We didn't get an agenda out, but I figure we'll pick up with the discussion from last time and talk about next steps.

Brian: Thanks to Majeed and Rob for the notes last time.  Anything folks thought was missed from last time?

<no corrections>

Rob: Access is a bit odd right at the moment -- Drew is working on changing things around.

<general agreement that the notes will need to be available for review 

Majeed: I'll take notes too.

Brian: So, moving on.  I didn't check to see if Chris is here... Chris -- I think you had an action item to send along some collateral material from the Canadian access federation that he shared last time. Would love to get that stuff passed along, but we can talk about how you want to do that if you want...

<Chris Phillips isn't on the call>

Brian: Etan and I will try to track this down and get an update on that.

Brian: So moving on to the survey: Folks know where the survey is? <added to chat> Appreciate the folks who did take the survey, and I encourage everyone to take it as Etan noted -- this is to both get input from the schools but also to get to know about each other and to get a sense of the pain points we need to focus on.  I thought it might be good to look for trends in the responses so far.  One trend I noticed is that getting the group that manages Shib and the group that manages Microsoft stuff together to help work out the interface there. That was mentioned in a few different responses.  Any other trends or things folks want to call out?

Etan: I haven't had a chance to look at the responses much since folks started filling it out.  I know it's still growing, and I'm a little distracted for the moment...  I will point out that I see the majority of entries (maybe all of them) are from sites running Shib.  That's one bit of common ground I see.

Brian: There's a lot of Microsoft specific drivers in the data.

Etan: I know from our site, there was a demand to get the Microsoft stuff working because we became an Office 365 shop.  Our state govt. got a great deal for us with Microsoft -- it's a general educational agreement with Microsoft that gets us all sorts of discounts.  For us, it was that we need to get M$ working.  Now, our initial IAM started at Hopkins with SiteMinder -- that was our first SSO solution.  It was completely proprietary and used no standards -- it was garbage in that sense.  A couple years later, Shib 1.0 came out, and we were trying to be part of or get into the InCommon federation, so we needed to get Shib set up.  We needed to avoid multiple logins for users, so we set it up using the old RemoteUser hack to get Shib to authenticate vie SiteMinder.  We later put ADFS behind Shib -- Shib protected ADFS, and SiteMinder protected Shib, basically.  We then had all three of those working together at one point.  As time went on, we started going more toward Shib instead of SiteMinder because of issues with SiteMinder, and we were a lot more familiar and able to design things with Shib, so we eventually got rid of SiteMinder as the main login.  We eventually needed to get Azure into play, and there was a demand to have Azure do MFA for us -- the MFA was the driving force for getting Azure to take over everything.  I started out trying to get Azure to work with SiteMinder, but then realized we would be better off with SiteMinder out of the picture.  For a while, we had ADFS protecting Azure, with ADFS hanging off of Shib...  We finally got SiteMinder behind Shib, and then got rid of ADFS.  So at this point, we have Azure doing login for Shib, and everything else hanging off of Shib.  Only took about 17 years to settle down at Hopkins.  The first five years were just direct LDAP authentication (before SiteMinder) :-).  Our driving factors have always been (and probably are for everyone else) that there's some application that needs to use some specific SSO solution, and that's why we need something specific. SiteMinder came in because SAP told us they supported SiteMinder directly (turns out they didn't without purchasing more stuff).  We got into Shib because of InCommon, ADFS because of SharePoint, and Azure because of Office 365.  It seems like it's always apps driving SSO technology.  Even with us adding OIDC to our Shib (via the plugin) -- that was because apps wanted to use OIDC.

Etan: Going forward... I think we need to view things from the perspective of the protocols and the apps that are in play.  You have an app -- A...  You can view it from the user perspective, or from the protocol perspective.  From the user perspective, we decided we didn't want to use our homegrown login page anymore, and decided to use Microsoft's login page and MFA, so we went that route and made Microsoft our front end.  Some folks want to keep their on-prem login page (I think Majeed mentioned this before) so that might drive an ADFS solution...

Majeed: We tried to use the global Microsoft login screens, and I'm not completely done with the membership survey yet -- I kinda gave our history...  SSO didn't start at our school until 2007 or 2008, then we went with CAS for about 7 years...  We tried to use the Microsoft global page, but there were a couple things -- I can give more detail if you want -- we had several cases with Microsoft... The major blocker was the three links that all went to SSPR...  We weren't doing SSPR, so our users could do password changing, couldn't do login failure reporting...  We had other issues open in separate cases, and our accessibility folks had a lot of due diligence to do...  They ended up having some heartburn around Microsoft's pages (some of which we actually got Microsoft to make changes for).  Even though they made some changes to the pages for us, we couldn't really get into running SSPR and such quickly enough to use their login page directly.  Our major driver for it was using their MFA.  Now that we have MFA via Azure, no one wants to pay for another solution, so we're kinda locked in to using Azure for that...  As we moved forward, we ran into the InTune issue -- our laptop provisioning folks wanted to use InTune for hands-off provisioning of new hardware.  So at that point we needed to have Azure in the mix to do MFA and to have Shib the mix for InCommon. I guess InTune and Autpilot are the "app" that drove us in that direction

Brian: I threw a couple links into the chat (these were things I couldn't talk about before under NDA but they're public now) -- There's some custom branding support coming to the Azure AD sign-in page.  There's also some SSPR change -- the sort of "I've lost my credentials" thing can now be customized and branded.  So Azure might be an easier option for you now.

Majeed: Yeah -- when we had our issues, Microsoft told us they were *working* on options, but they weren't ready yet, and we weren't able to wait for our deployment.

Brian: I'm really excited about this because we have some disclaimers in place to try and steer folks away from things that won't work in our environment because of these issues -- now that they have added some customization there, it's going to make things easier for us.

Majeed: Yeah -- we could have users get stuck in loops between Microsoft and our local self-service stuff in some cases with the configuration we've had without SSPR.

Etan: Microsoft is looking into some stuff for us along these same lines -- user account binding support.

Brian: Azure has some nice features in B2C for that, but those features aren't in Azure AD, so they're not really useful for us.

Etan: What we have now is a local tool where they enter their DOB, SSN-L4, Name, and then they can set up their account.  We're having internal discussions about rebuilding that (it's in Cold Fusion now) -- in the process of rebuilding, the question arose of whether Microsoft could do it for us in Azure AD.  Microsoft says not quite yet, but maybe eventually...  We're hoping they'll come out with additional support there.  We went with SSPR, so password reset and password change are done with the Azure tools.

Majeed: It's nice to be able to use the MFA mechanism from Microsoft to allow password resets -- that's not easy to get in the custom service we have (using Azure MFA).

Etan: One gotcha to be aware of (we ran into this) -- if you have occasion to reset a password because the account's been compromised, make sure you reset their MFA at the same time (otherwise you've just opened up their account).  When we ran into the problem, our group (Enterprise Authentication) was responsible for setting MFA, and the directory team (separate group) was responsible for resetting passwords.  Directory folks would update the password, and in the 5 minutes it took to reset the MFA, the user would have reset the password, and then they'd be able to use the password to reset their MFA, opening a possibility for re-compromise.  We built a one-button tool that does the whole thing as a single step.  We haven't gone *quite* as far as disabling accounts on compromise yet, but that's probably where we ought to go if we want to be sure...

Etan: Terminating active sessions is of course a separate piece.

Majeed: This is on the high friction list, right?  Session revocations are challenging in multi-SSO systems.

Etan: Some things are easier than others -- Azure will let you invalidate sessions all at once, but Shib sessions can't really be invalidated in that sense.

Majeed: There was some talk about at ACAMP last year, I think... Scott mentioned that it might be something they'd add to the attribute resolver so that any time the user comes through an authentication flow, the attribute resolver could check an administratively disabled attribute that would automatically run the user through SLO (if that's even applicable in your environment).  That's about the only thing you could do in the Shib case for that...

Etan: Knowing how Scott feels about SLO, I'm surprised he'd even say that much about it. :-)

Brian: Any other observations based on the survey or anything folks note there they want to bring up at this point?

Ryan: I may be a launching point for some of this discussion... ADFS... Since Microsoft isn't actively promoting it anymore, we've had conversations with our AD team...  We're running 5 ADFS tenants on prem, and exploring moving to Azure AD...  That's prompting more conversations.  We've moved all of our services off of ADFS, save for email, of course.  Everything else is transitioned to Shibboleth over the last two years.  That might be a discussion point -- where others are thinking about linking systems -- if we're sunsetting ADFS, maybe the exploration point is Azure AD SSO and then whether AzureAD SSO can be used exclusively or whether there are touchpoints where Azure and Shib can work together.  There are a few institutions already responding who have ADFS and are probably in a similar situation...

Etan: That was part of the discussion last week -- the fact that the future of ADFS is not clear in the long term.

Brian: Good observation.

Brian: So, moving to next steps.  We have a few things in progress -- the survey (and we'll review it again next time).  Another thing we have in progress is the stuff Chris P showed us last time -- their analysis of various solutions in the space, and the way they help represent what kind of solution is adequate or not.  As we get some of that collateral material, we'll have more to talk about...  So, a couple things in transit.  What's our next step?  Do we start tackling some of these hot spots and start documenting solutions?  Do we continue having conversations around what we've done locally at our sites?  What's a good path to take here to move this forward along our chartered path?

Majeed: It feels like getting some of those scenarios documented -- similar to what Chris showed last time -- whether we do it with some drafts in our private space or whatever, it might get us closer to our deliverables...  Maybe we review the charter again and clarify those goals?

Brian: I agree -- we need to start writing down some of these solutions we've discussed, and others have also talked about and and some have even noted them in the survey.  Getting some of this written down in a way that is flexible enough that other people could take advantage of them would be a really good step forward.  It feels like we're kinda talking around problems at this point and not getting to solutions.

Ryan: I'd love to see something like that.  The various applications for SSO -- and then the various pros and cons of different arrangements.  Shib proxying for Azure, then Azure proxying for Shib. We could then start throwing in different components and noting the pros/cons, pitfalls, rationale for doing one or the other...  That would be helpful, I think.

Majeed: Might be nice to kinda get some sort of naming scheme for these patterns.  EG, the one where Shib is proxying out to Azure AD and Azure AD is the primary login provider.  The use cases for that -- is the institution trying to integrate all SSO via Shib with a single Shib -> Azure AD integration, which provides an exit strategy if Azure becomes something you want to undo... I know the vendor lock-in ship has typically sailed by that point, but it's still worth considering. That's different, eg., from going in the other direction.  Etan's proxying setup is different from ours, for example -- I'd probably call them separate models.

Etan: I think it's not just what you have, but it's also how you have them configured and how they interact.  The what, the how, and the why.  I tried to cover that with the survey, kinda -- SSO techs are the "what", order is the "how" and the "what situation requires more than one" is the why...  But I think we could expand on that...  I could take our implementation of Azure AD and Shib and OIDC and write up a "This is what it is, this is how we connected them, this is why we connected them and why we did it in this way".  We could maybe have everybody go back and write up something like that for their implementation...  Or we could have people "claim" a solution model and write it up..  I could do our model, Majeed could do his model, someone else could take CAS + Azure, or whatever...

Michael (CSU): Maybe two quick questions: When we're all said and done, are we just looking for a set of documents or something else? And if we can agree on what that is, does it make sense to make some quick logical jumps to what's feasible and what we probably don't need to try to cover?  Start from a list of a handful of reasonable solution?

Brian: I kinda imagine something like what Chris showed us last time -- a big chart that maps the technologies and what they can support, along with a document that has a high-level summary of these "patterns" -- Shib proxying to Azure AD as a pattern, along with a summary at a high level of what that can give you.  Separate from that, I'm envisioning a somewhat more in-depth discussion of the ads/disads/pitfalls/ mitigations for the patterns we think are particularly effective.

Ryan: You can also think about for someone who's getting a fresh start or trying to modernize their environment -- if you're not heavily invested in InCommon and you meet the following criteria (already paying for AzureAD, for example), maybe we can produce a recommendation for that situation...  I don't know if that's an outcome we would provide?  Or if it's more just providing information rather than prescriptive recommendations.  Someone starting out fresh -- they don't see the advantages of, say, Shibboleth as a non-research institution?  Depending on every institution's unique needs, maybe it changes...  Are we going to provide recommendations or just an overview?

Etan: I think we kinda have to do it that latter way -- just an overview, because we can't know everyone's individual situation, so we can't say that X is better than Y without knowing a lot about your specific situation.

Majeed: Feels like the pros and cons will help the reader -- putting out the risks, advantages, disadvantages -- those will help the reader find the best solution for them.

Etan: I think we need to provide a sort of "here's the list of technologies and their pros and cons", "here's a set of linking strategies, and their pros and cons", and then "here's what you get and don't get if you do it in this order, or in that order"...

Michael (CSU): How many options are there reasonably in scope?

Etan: Lots

Brian: One of the things I was thinking of...  Here, we considered moving to Azure AD + Cirrus Identity Bridge.  WE can't go that way because we have a lot of Shibboleth dependencies that we can't migrate off of quickly.  ON paper, it looks like it would work out really well, but in reality for us, it wouldn't.  That sort of argues for the latter case.  I can imagine Universities that don't have a lot of investment in Shib today and want to be in InCommon, but don't want to start up Shibboleth, wanting to use Cirrus.  I don't know how common that is, but I can imagine some Universities taking that path.  And there are other solutions than Cirrus -- that's just a placeholder...

Etan: Is anyone running Okta?

Michael (CSU): We have a couple campuses running Okta.

Brian: A lot fo sites I surveyed a while back are using Okta.

Etan: Shib, Azure and Okta seem to be the three big players in the space that I seem to see today.  They're the ones I see/hear about most often.  Was just curious if anyone's done linking with Okta from inside our group?

Michael (CSU): We have a couple campuses that use it and have done a lot of work with it over a couple years.  If we need some help with that, I can probably pull in someone from one of those campuses to help.

Marcus: I think one of them is using Cirrus and one of them is doing something else, so we have multiple perspectives possible.

Etan: I just noted it as a gap in our list of technologies.

Brian: So, it feels like coming up with some sort of shot-ish list of solution patterns might be a next step , and then assigning a couple people to come up with perspectives -- pitfalls and downsides and the features of those patterns.

Ryan: I think that's a good idea -- Can you share again what Chris showed last time?

Majeed: There was a brief description -- Chris offered to attach it tot the wiki page -- once we get access straightened out he can add some screen shots.  In his document, each row represented a specific product -- shib, or CAS, or Okta.  Each column was a feature -- does it support it or does it partially support it, or not support it at all.  Lots of different features listed, along with points about what sorts of expertise are required to use it, etc.  I think it was a great model for something like that -- for our purposes, we'd just replace the single technologies down the left column with combinations of linked solutions.

Brian: I felt there was some agreement with my idea, so maybe Etan and I can set up a page and start a list of options and try to get the list sufficiently specific that we can tell what each item is.  Then next time we can maybe talk about what those are, vet whether it's complete, and do some assignments.

Brian: We only have a couple more minutes -- any other topics?

Rob: If Etan and Brian want, I can try to help ping Chris (since I have a couple other meetings with him this week) about getting that material linked in the wiki.  Also, I'll keep working with Drew on getting the permissions straight in the wiki, and let everyone know if it looks like we're fixed...

[ adjourned at 14:58 ]