Attending: Rob Carter, Etan Weintraub, Brian Arkills, Marcus
Mizushima, Shilen Patel, Majeed Abu-Quibain, Jeffrey C (UCLA)
Regrets: Les LaCroix
<Start recording: 14:06>
Etan: Reminder: this is recorded. It won't be published, but it will
be used to help with notes and such. I think that's the
Rob: I'll help.
Majeed: I'll help too.
Etan: On that note: From out last meeting, I had a task to generate a
linked IDP scenarios document, and a table we can use to manage that.
Fortunately, Brian started that and saved me the trouble of starting
it. I made a few modifications, and the result is in the private area
of the working group wiki.
<Etan screen share>
Etan: What we've done is lay thes out with "login IDP" (which is the
IDP that's at the top of the stack -- where the user actually logs
in), then "linked IDPs" (which could be more than one), method of
link, issues, significant benefits, and then if you need to break out
more details and who the responsible party is for the scenario.
There's a way to sort these things, so... I'm taking the Azure
(login) -> Shib (linked) scenario. I'm taking that one. You can @
yourself in the "WG Responsible Party" field to take one.
Etan: We have different models depicted -- Shib->Azure AD, Azure AD ->
Shib, Azure AD -> Cirrus, etc... The ones you can see there are the
ones we have right now. I'll try to go in over the next two weeks and
put in more info on the one I've claimed -- stuff about benefits,
Etan: Now that I'm talking through it, I wonder if we should put in a
field for "reasons" for going this way -- it might fit under
"benefits" as well -- but some reference to why an org might want to
use this scenario.
Etan: Does anyone else want to claim one while we're here?
Jeffrey: Our institution is looking into Okta, so I'm wondering if
anyone from a school with Okta would be interested in getting one of
those scenarios into the mix?
Etan: I don't recall anyone mentioning Okta as something they're using
in the member survey... We looked at Okta a while back, but decided
Azure was just as good for our purposes and cheaper., but we can look
and see if anyone has Okta experience or is actively using it and see
if we can get that into the mix. Are the other of the listed
scenarios people want to take?
Majeed: I'll definitely take the OAM->CAS one. Is that too
special-case for our environment to be useful for our purposes,
though? Maybe from the perspective of a migration example -- it could
be a linkage for migration purposes.
Etan: I think it's useful to share the information. Maybe at some
point we separate things out so we have recommended solutions and
other solutions we've got information about, and this might not be a
Majeed: Yeah -- this is something we wouldn't want to do forever --
for the long term, we wouldn't recommend it, but it's a way out of a
legacy system. I might also think we might want to have something
about linking into Azure AD in order to use Azure MFA (possibly with
Shibboleth). We combine Shib with Azure AD to use Azure MFA with Shib
for the login page. (AAD->ADFS->Shib w/ Shib login and Azure MFA for
shib protected apps)
Brian: That's a unique scenario we should probably have a different
Majeed: I can take the AAD->ADFS->Shib(MFA) one.
Etan: Any others? I can't take Cirrus...
Jeffrey: There is a use case we have but I don't recommend that has to
do with using some custom Unicon code to link Shib to Okta because our
medical enterprise uses Okta... But if folks want it documented, I
can get it in there.
Etan: It may be worth getting that in there just for purposes of
noting that it's *not* recommended, because some folks may think of it
as something they *could* do, and be interested to know that we don't
recommend it (explicitly).
Jeffrey: Not sure how to put it down, since it's a sorta strange
dependency -- sometimes users us shib, sometimes they use Okta -- but
I can take it if we can figure out how to describe it.
Brian: I put into chat that there are quite a few univs using Cirrus
-- you can put me down in Cirrus, since we explored it pretty deeply,
without actually getting the product. It'd be great if we could get
one of teh R1s actually using Cirrus that I put in chat (IAState,
Yale, Berkley, Mich, MIT, CMU, Indiana, Arizona, Oregon) to report for
us on it.
Jeffrey: And we want folks who actually have things deployed, right?
Not just have Cirrus report on it for themselves?
Brian: You can put me down next to the other Shib/Azure Ad environment
-- we were in that configuration for 9-10 years before -- I have a lot
of experience with it, but we're not using it anymore.
Etan: We were in that mode too, but I didn't like it and I didn't want
to take it because of that. We had SiteMinder in front of Shib, then
ADFS, then AAD -- it got to be a nightmare.
Jeffrey: I am curious about the specific reasons (apart from
complexity) that drive you to unfederate Microsoft stuff. Not for
this conversation -- just thanks for offering to take that topic,
since it would be nice to understand why you chose to unfederate.
Brian: I had originally put in a row that was essentially an unlinked
scenario, but I removed it because it's not really topical for us.
Etan: Right -- we should probably have scenarios where we're actually
Jeffrey: But it's about the experience, right? We do have linked
scenarios on the list, but where someone's decided to unfederate and
undo a linkage altogether, the reasons for that linking are probably
Etan: Well, we just got rid of ADFS.
Jeffrey: Yeah -- I think Brian's situation was more that they chose to
unfederate the application environment, and why that happened would be
interesting to discuss, for folks thinking about making that decision
-- looking to federate for the user experience use case, but if there
are reasons they might want to consider that doing that would be
undesirable, it'd be useful to know that.
Etan: From our perspective, we want to have one user login -- any time
we have more than one, we find that users are much more easily
phished. Phishing is a major problem, and we've gone to a very strict
"everything must use our websso" model, and if you have a problem with
that, you need to talk to the CISO. We're staying federated in Azure
because of that. As far as why we made AAD the front end and then
shib, it was mostly because we got a directive to use AAD MFA rather
than our own home grown one, and it made more sense to use Azure for
everything if we needed to do that than to do all the back-and-forth
that would be required otherwise.
Jeffrey: That makes sense. I didn't mean to derail us, but...
Brian... Your use case for *un*federating... You have both a Shib
login page and an AAD login page and that's not a problem for you?
Brian: And prior to that, we had uses going to AAD, putting in their
UPN, then get redirected to Shib where they enter their userid a
different way, then they come back to the MS experience and they get
the "you're signed in" dialog from Microsoft... So to say that we had
a single SSO experience was kinda false in that configuration. It's a
convenient bending of the language to say that, but the experience was
actually not that. I think Etan's configuration is a bit more SSO in
terms fo the experience, but it's the reverse direction, so that
experience is different.
Brian: The token lifetime issue we ran into was a major issue, and our
primary ADFS support person left, so we were having trouble supporting
that. And we were starting to see some edge cases where federation at
Microsoft wasn't working quite properly. On the Microsoft end, they
like you to be in a "managed" rather than "federated" configuration --
password hash synchronization or passthru authentication to a local
AD. Their experiences for apps inside Microsoft are a bit better than
if you're federated... SQL Server folks at Microsoft were promoting
some odd scenarios where Microsoft could have SQL servers be able to
authenticate as arbitrary users in your tenant with federation, and
claiming it as an advantage of federating, but we saw it as... not an
Majeed: From our perspective, a lot of it has to do with simplifying
how many different environments we have to manage and have to teach
our users to navigate. We do things with HRD replacement that get
around some of the experiential stuff (people getting asked for their
email address to find the right IDP to access from the Microsoft
federation endpoint). That only works in specific cases that we care
about, but it works for what we care about.
Brian: I didn't cover our MFA scenario -- we had to do a bunch of
customization to get MFA to work properly (with only one MFA prompt
for users accessing Azure AD apps) when we got MFA started. We
preferred because of that to go with unfederated. I imagine over time
we may gravitate toward something like Etan's solution, but because of
the individuals involved here at the time, that wasn't going to
happen. I think the folks on the ground here are probably supportive
of moving in that direction, though -- it's just a matter of when
we're ready to make a decision.
Majeed: Thanks -- sorry for derailing.
Etan: No derailing at all -- I think this is stuff we should discuss.
In our environment we have things that are directly using Azure AD and
not going through Shib, but we try to get everything to go through the
full stack. We have failover in the event of a network outage on the
outside that gets around the linkage.
Jeffrey: Can you tell us more about how you do that split between
using AAD directly or using AAD + Shib?
Etan: We took our old on-prem login page and built it into an apache
forms environment. We Have a backup IDP running in a separate Tomcat
that has a different configuration and doesn't depend on AAD. Once
upon a time we had it set up as separate servers, but we moved to
newer servers with multiple tomcat instances. we have a script that
flips a deployed system from one plan to the other. It changes the
reverse proxy configuration in the Apache configuration and restarts
Apache on each box to effect the flip.
Majeed: When you switch to the failover, you're using MPS for MFA
Etan: In failover, if Azure is up, we do MPS, but if not, our on-prem
MFA (RADIUS-based) will work, but only for those of us who have that
available. We use that for our text messaging MFA and a few other
things, so we recommend that users get enrolled in the backup MFA
system... We haven't quite gotten to the point of being able to take
the Microsoft phone number and put it into the text system
automatically to do text-based MFA... Has to do with carrier
information being hard to come by for telephone numbers in Azure...
Etan: So, I'm gonna try to take Brian's advice from earlier and say if
there are no other conversations we need to take now, we can adjourn
early. I'll send something to the list about this linked IDP
scenarios page, and get folks to come in and volunteer ones that
aren't taken already.
Shilen: We can add a row if you want for our IDP extension for doing
WS-Fed/WS-Trust to get around some of the issues with linking to
Brian: We can add a row for that -- I think it's worth adding a row
for that, too.
Brian: I aslo shared a link in chat to an analysis we did a few years
ago when we started thinking about doing MFA with Azure AD -- it has a
structure similar to our rows with info about where 2-factor
enforcement point would be.