[HN Gopher] SAML Is Insecure by Design
___________________________________________________________________
SAML Is Insecure by Design
Author : aj3
Score : 106 points
Date : 2021-08-04 19:01 UTC (1 days ago)
(HTM) web link (joonas.fi)
(TXT) w3m dump (joonas.fi)
| jimmaswell wrote:
| The vulnerabilities happened, we're aware of them now, and the
| major libraries (which you should be using anyway) will be sure
| to fix them. This isn't a compelling case to throw away SAML,
| just to be mindful not to make certain implementation errors.
| dmarlow wrote:
| Does FB use SAML for their login flows? I know Google has several
| different options and SAML is available, but was unaware about
| FB. Maybe in one of their more enterprisey apps/services?
| hirsin wrote:
| If you want to federated eg AAD with Gsuite, it'll be via SAML,
| but I don't know of any consumer service that's ever supported
| SAML. It's so weird the author used Twitter when they were one
| of the classic original Oauth creators.
| stouset wrote:
| On top of this, I have inside knowledge that some extremely
| common libraries that implement SAML were built not by reading
| and understanding the spec, but simply by looking at sample XML
| documents in the wild and writing code that handled it.
|
| Multiple exceedingly obvious vulnerabilities have been the
| result. One fun one was: looking at an XML signature in the
| document, verifying it, then ignoring the assertion it was
| claiming to sign and just trusting the assertion at the document
| root.
|
| I tried to write a standards-based implementation and gave up.
| The standard is enormous, and consists of three parts:
| 1. The definitions of what each XML tag means in a vacuum
| 2. Patterns on how to assemble those XML tags into a document
| that means something useful 3. Protocols that exchange
| these documents back and forth to accomplish some authentication
| objective
|
| Half the problem comes from the fact that it's meant to do
| anything and everything, and so you can theoretically just mix
| and match all the above parts to get what you want. But that also
| means that it's exceedingly simple to mix and match stuff in ways
| that are subtly (or not so subtly) insecure. The other half comes
| from the fact that the standard is so damned complicaed in order
| to handle everything under the sun that it's damn near impossible
| to wrap your head around it all. So people just glance at the
| spec occasionally and just write something that handles documents
| they see in the wild and hope for the best, with predictable
| outcomes.
|
| The whole thing is a tire fire.
|
| Note, I last worked with it about a decade ago so I may have
| gotten some of the characterizations wrong.
| lol768 wrote:
| > On top of this, I have inside knowledge that some extremely
| common libraries that implement SAML were built not by reading
| and understanding the spec, but simply by looking at sample XML
| documents in the wild and writing code that handled it.
|
| Yup, and its complexity leads to something of a shortage of
| libraries in the first place so there's not much choice.
|
| There's still no good modern maintained OSS .NET 5 library for
| doing SAML. There are some commercial offerings (ComponentSpace
| have a neat product and they weren't affected by VU#475445
| either) but my worry is that folks will end up using whatever
| free libraries they can find without thinking too much about
| the consequences.
| 8mcoLwmQoWZ3s wrote:
| By "doing SAML" do you mean from the server perspective or
| the client perspective? This simple client library works with
| .NET 5.
|
| https://github.com/jitbit/AspNetSaml/
| stouset wrote:
| This client library is nowhere near enough by itself. I
| could tell this within five seconds, as it's a single
| source file only a few hundred lines long.
|
| It checks that you get a signed assertion back, which is
| valid, and lets you pull out attributes. That's great, but
| there are a gajillion tags that can be set within an
| assertion that have genuine, important security
| implications and zero of them are handled by this library.
|
| If your IdP sends those tags along with the assertion, this
| library will happily ignore them unless you implement
| support yourself. And I would bet heavily that
| approximating zero of this library's users write that
| support.
|
| One trivial example, there's a `<saml:Conditions>` tag.
| This tag can have all sorts of attributes like `NotBefore`
| or `NotOnOrAfter` that specify a time period for which the
| assertion is valid. This library does not do anything to
| implement support for `<saml:Conditions>` tags _at all_ ,
| so every consumer of this library will happily process
| assertions as valid even if they're outside of the duration
| for which the IdP is claiming it's valid. There are other
| attributes that can set conditions, and there are other
| tags with implications on whether or not an assertion
| should be considered valid. None of them are handled.
|
| Further, only minimal document validation is performed. The
| signature is checked, but the Issuer is not. Multiple
| Issuers _can_ share a signing key, though I suspect actual
| cases of this are rare. At any rate, there 's a billion
| ways users of this library can blithely chug along with an
| assertion that isn't valid and shouldn't be trusted, but
| nobody notices or cares because the happy path works.
|
| With authentication, yes it's important that legitimate
| users are able to sign in. But it's _as important_ that
| illegitimate authentication attempts are disallowed. And
| this half is completely forgotten about in literally 100%
| of the common SAML service provider libraries I 've seen in
| the wild (which is admittedly not 100% of the ones
| available, just the ones I've looked at).
| tptacek wrote:
| This is neat, because every program that actually uses
| this library probably has the AudienceRestriction authz
| vulnerability. It doesn't look like it's checking the
| Response Destination= field either.
| mwcampbell wrote:
| If I'm not mistaken, the correct terms are identity
| provider and service provider, respectively. After all,
| they're both servers, in the sense that they both receive
| requests from the other.
| janci wrote:
| Isn't this the usual practice with any nontrivial XML handling?
| You get some WSDL and XSDs of a _coarse-grained_ service (as in
| having 300 optional input elements with no idea what can be
| combined or not) so you throw real-world examples on your
| implementation until it works.
| stouset wrote:
| "Throw stuff at it until it looks like it works" is probably
| not the development practice you want to employ for an
| authentication service.
| janci wrote:
| Surely not! I'm just saying I'm not surprised too much.
| jrockway wrote:
| I think there's a mismatch between security and software
| engineering. Software engineers are paid to make things
| work, but the point of security is to make things not
| work (for attackers). So there is that fundamental
| mismatch which leads to a lot of strife, I think. (The
| real answer, of course, is that the software needs to do
| two things instead of just one. It needs to permit
| authorized users AND deny unauthorized users. One is not
| more important than the other, both must work perfectly.
| But when testing it, you're mostly happy when you, the
| authorized user, are allowed to log in, and so tend to
| forget about the "what if the assertion is malformed"
| case.)
|
| I think it's funny because engineers are always portrayed
| as being grumpy and that they hate everything, but if you
| look at how they handle errors or security, they seem
| like the type of people that like everything and always
| imagine the happy path ;)
| michaelt wrote:
| It is indeed a common way of parsing XML. Unfortunately, it's
| a bad idea when dealing with SAML.
|
| SAML is a way for exchanging 'security assertions' - for
| example, if a Alice logs into the AWS Console with her
| employer's single-sign-on service, the SSO service gives
| Alice a signed document saying "The bearer of this document
| can log into AWS as Alice within the next 60 seconds and
| access accounts B and C" which she hands to AWS. The digital
| signature on the document is _very important_.
|
| Unfortunately, SAML uses the 'XML Signature' standard [1]
|
| The people who wrote the XML signature standard didn't just
| take an XML document and whack a PGP signature around the
| whole thing! They thought about use cases like 'what if you
| wanted to only sign part of a document' and 'what if, after
| signing, the document was processed by something that
| reordered the attributes' and 'what if you have signatures
| from multiple sources and want to collate them into the same
| document'. They decided they wanted to support all of them.
|
| As such, it's entirely legal for a document to contain a
| valid set of properly signed security assertions _and_ a load
| of different security assertions that _aren 't_ signed.
|
| So SAML documents have to be parsed very carefully - if you
| naively check the document has a valid signature then read
| the assertions, an attacker can add extra assertions outside
| of the signed part of the document, granting them broader
| permissions than they ought to have.
|
| [1] https://en.wikipedia.org/wiki/XML_Signature
| bawolff wrote:
| > The people who wrote the XML signature standard didn't
| just take an XML document and whack a PGP signature around
| the whole thing! They thought about use cases like 'what if
| you wanted to only sign part of a document' and 'what if,
| after signing, the document was processed by something that
| reordered the attributes' and 'what if you have signatures
| from multiple sources and want to collate them into the
| same document'. They decided they wanted to support all of
| them.
|
| You forgot to add the part - what if someone wants to add
| comments randomly without it changing the signature, even
| when those comments (mildly) change how the xml doc is
| parsed!
| stouset wrote:
| I did forget. I've spent years trying to.
| jrockway wrote:
| I feel like we keep making this mistake again and again.
| Like JWTs can be signed with the "none" algorithm, which as
| you might guess is very easy to forge. Conformant
| implementations can see that and say "yup, that's a valid
| signature" and happily let any user grant themselves any
| access they want. Big mistake. It probably shouldn't be in
| the standard.
|
| (I like PASETO instead of JWT, but nobody else in the world
| does, it seems, so we're stuck with the broken thing
| forever. Client libraries at least special-case "none" now
| and make it auto-fail, which has probably saved a few
| people that didn't actually read the spec.)
| jcranmer wrote:
| I get the feeling that this seems to be a common issue with any
| authentication or authorization "standard" nowadays. When I had
| to implement SASL OUATHBEARER support, and I started poking
| around how to actually implement OAuth2 from the standard
| itself, it was similarly full of "here's several ways that you
| might do something, and whether or not they're supported by the
| provider is implementation-defined, and what you have to
| provide with the requests is implementation-defined, and where
| you go to find the stuff is implementation-defined."
|
| And frustratingly for me--trying to implement this in the
| course of a SASL method as a client--there's not even anything
| hooked up in SASL that might have hinted at the client what to
| do. Which is insane because the entire point of SASL is to
| bridge the gap of "how to request authorization given username,
| hostname, protocol." It makes me want to retreat back into
| Kerberos as a better way of supporting SSO than anything
| invented in the decades after it.
| bawolff wrote:
| XMLSignature is one of the worst security specs i have ever
| read. If you want to learn what not to do, just read that.
| aidenn0 wrote:
| I ran into a similar issue trying to write an FTP client
| implementation from the spec. It turns out that most servers
| don't support 90% of the spec, and some very important things
| (such as the output format of LS) are completely unspecified.
|
| I threw out that first implementation and just got the 3 most
| popular servers and made it work with them.
|
| Random example: I'd like to present directories and files
| differently so users can chdir to a directory. There was no
| single method for detecting a symlink to a directory that
| worked on any 2 of the 3 servers I targeted for support (other
| than issuing a CHDIR and checking for success, and I wasn't
| going to issue a CHDIR for every item found when listing a
| directory for performance reasons; I did have to issue a CHDIR
| for every symlink on one of the 3 though).
| cmckn wrote:
| I was once tasked with writing a crawler for FTP servers and
| lost about half the hair on my head over this madness. Just
| when I tuned the robot to work with 10 servers, an 11th would
| pop up that behaved totally differently. Thankfully, I'm not
| in that job anymore -- I'll probably never touch FTP again.
| sleevi wrote:
| As others have noted, many of these issues are fundamental to XML
| DSig, which is insecure by design. [1]
|
| However, the "what does the future hold" of OIDC is not much
| brighter. OIDC is based on JSON Web Tokens (JWT), which manages
| to avoid some of these issues (e.g. signs the encoded value), but
| introduces new ones (JSON interpretation bugs, algorithm
| substitution bugs, etc). They're similarly terrible by design
| [2].
|
| However, what OIDC does relating to signing is far worse. In many
| OIDC deployments, the idea is you use something called "OIDC
| Discovery" [3] to discover the expected signing keys for the OIDC
| server. You fetch those regularly (e.g. daily), and do so over
| TLS. With SAML, you exchange certificates, and then rotate them
| every 2-3 years (with things blowing up on expiration), but with
| OIDC, you often end up using OIDC-Discovery, and thus can change
| keys daily.
|
| This means that a single malicious TLS certificate can be used to
| MITM your OIDC Discovery exchange, and from there, impersonate
| any user from the identity provider to your system, the relying
| party.
|
| I spend my days in the TLS trenches, working to improve the CA
| ecosystem, but I absolutely would not trust the security of all
| users to a TLS certificate. The reality is that BGP hijacks are
| still a regular thing, as are registrar hijacks. Even if you find
| out about a malicious certificate (via Certificate Transparency),
| and revoke it, virtually none of your tools doing the OIDC-
| Discovery fetch (like programming languages or curl) support
| revocation checking, and even if they did, it doesn't work at
| Internet scale. To deal with this problem, some relying parties
| do a form of poor-man's certificate pinning, but now they're at
| risk of even greater operational failures than SAML expiration in
| the start.
|
| In practice, it seems plenty of OIDC clients just shrug and go
| "yolo" - if they're talking TLS to the IDP, that's good enough,
| and no need to bother with signature validation of the assertion
| at all.
|
| For all my hatred of XML DSig and SAML, I've seen few auth
| standards as bad as OIDC: because it looks good, but is hell to
| implement correctly. At least with SAML, you know it looks bad to
| begin with, so you're hopefully on guard.
|
| [1]
| https://www.nccgroup.com/globalassets/resources/us/presentat...
| [2] https://news.ycombinator.com/item?id=14292223 [3]
| https://openid.net/specs/openid-connect-discovery-1_0.html
| lol768 wrote:
| > However, what OIDC does relating to signing is far worse. In
| many OIDC deployments, the idea is you use something called
| "OIDC Discovery" [3] to discover the expected signing keys for
| the OIDC server. You fetch those regularly (e.g. daily), and do
| so over TLS. With SAML, you exchange certificates, and then
| rotate them every 2-3 years (with things blowing up on
| expiration), but with OIDC, you often end up using OIDC-
| Discovery, and thus can change keys daily.
|
| I would bet a lot of money that a non-trivial number of people
| do _exactly this_ in the real-world using SAML (Shibboleth:
| FileBackedHTTPMetadataProvider or DynamicHTTPMetadataProvider).
| It 's not always manually managed.
| runningmike wrote:
| It's not insecure by design: use is so complicated that you never
| look back when you get it working. Too complex , so too error
| prone for most devs makes the risks of vulnerabilities high.
| yokto wrote:
| ... which is a way of being insecure by design. Design does not
| happen in a vacuum and must take the context and the audience
| into account.
| baby wrote:
| Nobody wants to write or maintain SAML code
|
| ->
|
| SaaS and other types of companies start solving this issue at
| scale
|
| ->
|
| SAML becomes code that is mostly going through a handful of large
| companies that sell products in this space
|
| ->
|
| since the protocol is now centralized, it can be updated to a
| better protocol
| rustybolt wrote:
| > SAML uses signatures based on computed values.
|
| "Computed values" is almost as general as "unit". It tells me
| absolutely nothing.
| humodz wrote:
| Yeah, it'd much appreciated if the author explained that a bit
| more in the "why is saml insecure?" section
| eightnoneone wrote:
| He literally does just that in the very next section; "Why is
| signing computed values dangerous?"
| NavinF wrote:
| I assume he was being sarcastic
| mormegil wrote:
| Well the whole critique applies directly to the XML Signature
| Standard, doesn't it (of which the SAML standard is just a
| user/application)? And sure, it is very complex and prone to bugs
| and security issues in implementations. Cf. e. g. the list of
| potential problems in http://www.w3.org/TR/xmldsig-bestpractices/
| lol768 wrote:
| > Let's get rid of SAML.
|
| Good luck, it's prolific throughout so many enterprises and
| academic institutions.
|
| We might see some support start to materialise for OIDC as larger
| enterprises start to make use of e.g. AzureAD properly, but
| you're still going to see tons of universities especially running
| their own Shib instance. And larger enterprises are going to be
| difficult to shift off of SAML when they've had X years of
| experience with it and their supplier on-boarding processes are
| built around it.
|
| The entire Jisc UK Access Management Federation is based on top
| of SAML, so that'll power the vast majority of academic resource
| authentication flows. You can argue that security is less of an
| issue for this use-case (particularly when e.g. Sci-Hub exists)
| but I think it's likely that once you have the infrastructure
| set-up for this it gets used for more and more services.
| avmich wrote:
| > Good luck, it's prolific throughout so many enterprises and
| academic institutions.
|
| Peasy easy. Just start mounting SAML vulnerabilities attacks on
| all those organizations with friendly suggestions to fix their
| problems, on top of juicy demonstrations of dangers. After a
| few will be affected, a trend will appear - in all kinds of
| media, among other things - that one ought to move from SAML.
| Of course the teachings should be done remotely, from friendly
| jurisdictions.
|
| /s
|
| We have this problem with security for years, not, decades
| even. Vista (Microsoft OS) was universally hated - <appropriate
| xkcd picture with blinking Hitler inserted> - as it tried to
| address gaping holes in XP security; fortunately Win 7 was much
| more user-friendly, so security still had some wins. But not
| nearly "ultimate" wins, no.
| tptacek wrote:
| The problem is that while we're all pretty sure there are
| more grave SAML vulnerabilities, they're not super easy to
| find. You can't just read this blog post and then go attack a
| SAML system; finding SAML bugs is actual research.
| tandr wrote:
| (for a reference to "appropriate xkcd picture with blinking
| Hitler inserted" - https://xkcd.com/528/ )
| mordae wrote:
| _cough_ eIDAS _cough_
| lol768 wrote:
| > eIDAS
|
| I'm sure a lot of governments have based regulations and
| standards on top of SAML... it seems exactly like the sort of
| thing they'd be drawn to - "mature", more complex than
| necessary, verbose.
|
| Pretty sure Gov.UK Verify is SAML-based, though I get the
| impression the new single sign-on solution (now entirely in-
| house with no external IdPs?) will be OIDC based.
| jcims wrote:
| Until all of these old-ass systems that finally got to SAML move
| to a new SSO architecture this could largely be mitigated by
| using the HTTP artifact binding instead of POST or redirect.
|
| Getting rid of SAML will be like getting rid of SMS 2FA.
| tptacek wrote:
| I think I agree with all of this. SAML is by far the worst
| commonly-used industry cryptographic protocol (you could
| generalize and say "anything reliant on XML signatures is the
| worst industry cryptographic protocol", and if you go looking for
| stuff like that outside of SAML, you should know that a lot of
| the bugs are portable between systems).
|
| I think the root cause of insecurity here is the near-universal
| attempt to use general-purpose XML libraries to build SAML. When
| the Go instability bugs were announced, I think there was a
| general take from the Go community that `encoding/xml` was not an
| appropriate foundation for SAML libraries, and, in this instance,
| I think the Go community was right: I think it should have been
| self-evident that you couldn't safely build SAML on
| `encoding/xml` (it doesn't even really handle namespaces!)
|
| When I did my own SAML in Go at my last job, I wrote my own soup-
| to-nuts XML, including DSIG canonicalization. It was annoying,
| but you can't get SAML wrong; you need to be able to predict what
| every component in the system is going to do. What makes this
| worse is that most SAML systems defer the cryptographic stuff to
| libxml/xmlsec; for obvious reasons, some of them sane, nobody
| wants to implement DSIG themselves. But then they interpret the
| signed message in a general-purpose XML library, and now you have
| competing XMLs _in a single system_. It 's bananas.
|
| In the esoterica of DSIG, there are even worse problems. DSIG is
| a very flexible format; it has has pluggable canonicalizations,
| happily supports multiple signed subtrees under different keys in
| the same parent message, and supports both detached _and_
| embedded signatures. There 's a famous, respawning DSIG bug where
| you can trick validators into verifying a signature on one
| subtree but passing on a different subtree to the calling
| application. A researcher at Duo Security tricked SAML
| implementations by embedding comments in text fields, which,
| after canonicalization, tricked parsers into returning altered
| text fields. Technically, SAML responses are supposed to be
| strictly schema-validated, so you can't sneak arbitrary subtrees
| into the middle of a SAML response --- but there's at least one
| extension field in a SAML message that has an any-typed free-form
| tag.
|
| It's also worth remembering that SAML's problem domain is
| difficult even setting the XML part of this aside. It's pretty
| common to find very bad authorization vulnerabilities in
| multitenant SAML RPs, because you have to check mesaages
| carefully beyond their signatures. Many of the high-level OAuth2
| protocol issues port over to SAML as well. It's tricky to audit!
|
| People stick up for SAML because what it does (facilitating
| centralized SSO) is extremely valuable; it's probably more
| valuable than the bugs are harmful, as long as you're using well-
| known tools that people have already been incentivized to scrape
| for SAML vulnerabilities. If I was adding SAML support to
| something new, I'd consider _beyond_ all the standard SAML checks
| also rejecting any message that doesn 't have the same shape as
| what Okta, Onelogin, Google, or Shib generates.
|
| But if you have the option, I'd also say avoid SAML.
| mwcampbell wrote:
| How is Shibboleth SP's track record on SAML vulnerabilities,
| either patching them quickly or avoiding them altogether?
|
| My company needed to implement SAML SP support in one of our
| products so we could get academic customers, particularly those
| that are part of the InCommon federation. We contracted with a
| company that specializes in SAML and Shibboleth to help us get it
| right. We decided to use Shibboleth SP running in a container;
| that container also has Apache httpd (as practically required by
| Shib SP) and a little Python shim app that generates a JWT and
| passes it back to our main app. Hopefully that's a good way of
| using the nearest thing to a canonical SAML SP implementation,
| without running our whole application through Apache httpd. In
| case anyone's interested, our Shib SP container setup, with the
| Python shim app, is here:
|
| https://github.com/PneumaSolutions/shib-sp
|
| It's probably still too specific to our application, but might be
| useful as a starting point for others.
| bob1029 wrote:
| After having implemented this recently, I have to agree with many
| points. It just feels so clunky to me and there are really shitty
| caveats with sign out and session lifetime that I _still_ don 't
| fully comprehend after reading 2 dead trees worth of Azure docs.
|
| Ignoring all other business constraints, the most secure
| architecture in my mind is integrated security w/ single-instance
| applications which are isolated to their own physical hosts.
|
| Integrated security can include MFA as long as the additional
| factors are scoped exclusively to each applications' secure
| environment.
|
| There is obviously a huge convenience speed bump if you leave it
| here, but there are small, incremental enhancements you can make
| to dramatically improve the UX without centralizing everything at
| the convenience of your attackers. For instance, you allow users
| to link accounts between 2 popular systems, and then rely on a
| simple pin code or similar for quickly jumping between them.
| teknopurge wrote:
| The author did a good job, but these were(are) known issues for
| quite a while. TLDR: implementation bugs with known
| countermeasures.
|
| https://www.usenix.org/system/files/conference/usenixsecurit...
| (from 2012)
|
| We've implemented SAML for 10s of millions of users and devices.
| The spec is verbose, but the approach solves common business
| issues. My suggestion is to use SAML simply: federations and
| passing attributes between trusted parties, allowing to verify
| the payloads. SAML can do a lot, but keep it simple and use OOB
| services for more orchestration/metadata.
| explorigin wrote:
| This. Lots of SAML libraries don't fully implement the spec but
| I second what parent says. It does well for federation
| attributes.
| tptacek wrote:
| The other word for "implementation bug" is "footgun". Standards
| with lots of footguns are bad standards. SAML has a lot of
| footguns. It is a bad standard.
| ezekg wrote:
| > (Note: this post is all pseudo code - it's not real SAML.
| Here's _a real example_ if you're interested.)
|
| *clicks link knowing full well the travesty about to be
| witnessed*
|
| So many businesses want me to support SAML. I always say no.
| Fizzadar wrote:
| Aha, brings back memories. Had to implement SAML login as a
| Service Provider once - a true abomination of a protocol, will
| never go near it again, and that was the easier side of things.
| growup12345 wrote:
| I found it a tad bit childish with all the swearing. Swearing is
| acceptable and sometimes natural in live speech but writing swear
| words is ugly and shows a lack of education and class, even if
| the actual education is of the highest calibre.
| [deleted]
| teknofobi wrote:
| Why does Microsoft seem to default to SAML for organisations
| using Azure AD?
|
| All our enterprise customers on the Microsoft stack indicate SAML
| as the only viable option, whereas those on Google Workspace or
| on more custom IdAM setups in my experience don't care if you as
| a vendor prefer SAML or OpenID Connect.
| hirsin wrote:
| The Enterprise Apps section is heavily SAML based, but if you
| want to look up how to write an app for AAD you won't likely
| find any SAML docs, you'll find the OIDC docs and oauth SDKs we
| build. If you see other places where you feel we default to
| SAML, I'd love to fix that.
| aj3 wrote:
| Well, it is de facto standard in Microsoft world. Honestly, I
| don't actually share author's opinion, but it is well
| presented.
| merb wrote:
| where does it default to saml? btw. we use azure ad and only
| rely on openid connect.
| syshum wrote:
| Most likely they are talking about adding Non-Gallery
| Applications (Custom Applications) for SSO, the only option
| there is SAML
|
| For OpenID Connect the developer has to sign up with Azure
| and have their app to the Gallery, you can not add a custom
| add yourself
|
| Right now there are over 1100 Gallery apps using SAML, and
| only 500 using OpenID Connect
| hirsin wrote:
| This is inaccurate. Multi tenant apps can simply be signed
| into via OIDC and they're added to your tenant, if you
| allow it. All Microsoft apps use OIDC and are not allowed
| to use SAML, but SaaS app developers are not quite as far
| ahead.
|
| But yes, we don't support dynamic registration of apps for
| eg OIDC/oauth
| tehbeard wrote:
| So no OIDC for "internal" apps?
|
| I had thought I'd missed something when setting up some
| customers, and having to refactor to use SAML for SSO
| where we'd used OIDC for g-suite, but you're saying
| unless I throw it on the gallery (public app store?),
| It's only SAML?
| merb wrote:
| no. you register and you can either use saml or openid
| connect. btw. when you register your app you select if it
| is only for your tenant or for multiple tenants (or for
| microsoft accounts). your app never gets in the "public
| app store" unless you manually submit to. btw. this
| information is all public on their great docs.
| merb wrote:
| what are you talking? you can create openid connect
| applications in azure. and you need to sign up with azure
| one way or the other, saml 2.0 and openid connect
| applications actually need to have an app registration in
| azure which can only be created once your signed up?!
|
| basically the app registration process for openid connect
| and saml is basically the same one?!
| teknofobi wrote:
| It might just be cultural with the customers I've integrated
| with, but we've had a policy of requesting OIDC and then only
| doing SAML if that causes hiccups, and of a handful of SSO
| integrations with customers on the Microsoft stack there has
| always been hiccups. There might be other correlations here,
| such as the IT departments at Microsoft shops in our cases
| being more driven by consultants and managers.
| wtatum wrote:
| I've definitely seen this cultural bias towards SAML. I
| think it may be the case that a lot of enterprises have
| done a recent transition into Azure AD but have the same
| staff who had managed a legacy AD FS and have not adjusted
| with the times.
|
| My approach has been to use Keycloak as an identity broker.
| It's implementation is quite robust and supports a lot of
| flexibility in terms of mapping custom assertions and the
| like. But the actual application "only speaks OIDC" and
| relies on access tokens to be reissued by Keycloak.
___________________________________________________________________
(page generated 2021-08-05 23:00 UTC)