I have a more theoretical question about AD FS. If I use it as a STS (Security token service) for accessing some internal company information from outside of private company network (over internet), using Claim-based authentication, can I decide exactly what credentials will be used for authentication or is it pre-set by Active Directory policies? To be more accurate, could I authenticate form a device that is not registered in AD?
If you want to authenticate against ADFS from outside the corporate domain, you should install the ADFS proxy in your DMZ.
ADFS can be used to authenticate users against the Active Directory domain it is installed in, or trust tokens coming from a federated STS.
So, if you have a web application that trusts tokens issued by ADFS, you can use security protocols like WS-Federation, WS-Trust or OAuth 2.0 (in ADFS 3.0) to get a token from ADFS and use it to authenticate against your web application.
Device registration is not required to use these protocols.
HTH.
Related
As far as I know, Exchange does support WS-Federation, but it does not support SAML. At the same time I have IDP that does support SAML, but does not support WS-Federation.
Is it possible to configure ADFS as proxy? For example: Exchange OWA/ECP -> redirect to ADFS using WS-Fed -> and ADFS speaks to IDP using SAML -> user is getting transparently authenticated using IDP?
Thank in advance.
• AFAIK, if you are configuring Exchange on premises mail server, then you must have AD in your environment, thus, when Exchange OWA/ECP forwards requests to ADFS, those will be purely using WS-Fed protocol or internal Kerberos authentication protocol. So, if you want to forward credentials from the ADFS to the third-party SaaS platform, then a relying party trust must be formed with that IdP to which SAML token are supported.
• Thus, you should create a SAML 2.0 provider supporting RPT with the IdP platform (3rd party) in ADFS for SAML supported authentication. Though, you can’t authenticate claims with the 3rd party IdP by forwarding through ADFS but can send the claim tokens as authenticated attributes to the other IdP.
• Therefore, what you are asking is not possible as Exchange ECP passing claims to ADFS in WS-Fed and then forwarding them to the IdP in SAML supported token as ADFS doesn’t support forwarding the identities to other IdP for authentication or transforming the credentials protocol from WS-Fed to SAML.
Please find the below link for more details: -
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/ba-p/257584
For configuration of SAML 2.0 service provider in ADFS, please refer the link below: -
https://learn.microsoft.com/en-us/powerapps/maker/portals/configure/configure-saml2-settings
I work for a healthcare SaaS company where all of our SSOs use SAML 2.0, and we cannot use LDAP. We have one particular client right now who wants to use ADFS to SSO from their intranet to our site and seem to act as though LDAP is the only option (and that they can't produce SAML assertions for our handshake).
What is the difference between SSO and SAML? What can one accomplish that the other one cannot? Why would my company require SAML over LDAP?
What I'm theorizing from research but am welcoming correction on:
-SAML is safer than LDAP because of authentication/encryption (but I don't know the specifics)
-LDAP is more widely used with companies but SAML is often used with enterprise clients
-LDAP can also be used to control users' access to other programs/sites they have access to (i.e. IT and revoking access to a terminated employee)
Thank you for your help!
Using LDAP for authentication requires disclosing the user's credentials at the application. If the application is running in a different administrative domain (i.e. a SaaS app) this is less preferred since the user's credentials end up in a 3rd-party domain.
OTOH SAML allows you to sign in to the application without disclosing the user's credentials to the application itself which offers increased security. It also increases convenience since the user only has to remember one credential.
LDAP is an Identity repository.
SAML is an Identity standard that could use LDAP as the repository. Or it could use something else like AD.
Just a correction - SAML does not use SOAP.
You can configure ADFS 4.0 (Server 2016) to authenticate against an LDAP and ADFS supports SAML.
If ADFS was configured that way, you would use SAML for SSO, authenticate against a LDAP and get a SAML token returned.
We want to setup ADFS 3.0 to enable OAuth2 based authentication. I have read lots of documentation, but am still unclear if this is supported.
Can ADFS be used as an authorization server for oauth, or is oauth2 support in ADFS only meant to work as a client to another authorization server?
Any help for setting up adfs as oauth provider/server is appreciated.
in ADFS 2012R2 (aka ADFS 3.0), we only support the authorization grant flow. The only scenario is for public clients (say a mobile app on iOS/Android/Windows) to access a RESTful service and authorizing via JWT tokens. You can see this at https://msdn.microsoft.com/en-us/library/dn633593.aspx
With ADFS 2016 (which will release imminently), you have the full Oauth/OIDC support. With this you can build web apps, single page apps, API's, multi-tiered app systems that require On-behalf-of support, confidential clients (with support for windows service accounts acting as confidential clients). You can check this out https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/ad-fs-development
Premise:
I have an infrastructure where we have a custom RP-STS implemented with Windows Identity Foundation, providing SSO for a few websites. This STS communicates with the sites via WSFederation. This custom STS is about to be deprecated because the organization is adding an Open ID Connect Idp into the infrastructure.
The websites themselves (Episerver) contain all the custom made authorization logic already based on the claims the STS provides, and if we were to simply toss the STS we'd have to replace all of this logic.
Question:
What is the browser redirect flow to integrate our RP-STS to the openId connect provider in such a way that the end user browser gets a session for both our RP STS and the Open Id Connect IdP?
Personal thinking on how it might be doable (based on massive assumptions on how openid connect works), skip this if you know how to answer:
Website sends HTTP post to RP-STS containing username/password
RP STS responds to browser with redirect to OpenId Connect Idp (Redirect contains username / password, and a replyto address is set to the RP STS)
OpenId Connect Idp creates a local session (???) and responds with a redirect to RP STS, redirect contains auth_token. (I'm unsure of the parts that go into an openid connect login flow)
RP STS receives user token and gets / asks for user data, builds claims and builds local session
RP STS sends claims in SAML token via WSFed to RP site
Am I even close?
Further clarification:
I do not want to remove the existing STS, but abstract the new infrastructure change behind it so that from the end-user-sites perspective, identity objects and authorization logic will remain unchanged.
I need help specifically in seeing if the login/logout flow is doable between the STS and the Open ID Connect IDP
WIF and OpenID Connect are completely different protocols e.g. WIF is mainly browser based in the passive profile. The token types are different - SAML and JWT etc.
The way to do this is via OWIN (Katana is the Microsoft implementation). There are NuGet packages for both WS-Fed and OpenID Connect.
There are samples available for Azure AD - refer Microsoft Azure Active Directory Samples and Documentation that you could use as a guide.
OWIN would allow you to use both protocols.
In fact, have a look at IdentityServer3.
This is an open source STS implementation of both.
I need to restrict access to an external site so that:
users who are in the corporate network have full access to the site's functionality,
those who are not - only limited functionality.
In the corporate network users do authenticate against a windows domain. In the network I can set up a server/service which can do the identity verification. This is secure, I have no doubt, especially when it is inside.
The external site is not a part of the domain.
What I suggest to myself is to setup a service, which will authenticated users against, create a secure token and then re-direct users to the external site. So that users will authenticate there without entering password (maybe not even login).
I'm in doubt: how this can be done? How secure this can be? How much heavy/crypto development are there?
I assume that the secure token should be time-bounded, that both external site and internal auth service should support SSL/TLS (symmetric/asymmetric keys?).
Am I missing something here? Surely, I am, but what?
Make the external site a SAML 2.0 Service Provider (SP).
Set up an internal SAML 2.0 Identity Provider (IdP) to authenticate the corporate users with SAML 2.0 ADFS. Use SP initiated SSO and have the external site configured to hand off to your IdP with HTTP-POST.
The IdP can be configured to authenticate a user logged into your ActiveDirectory domain with a browser capable of NTLM transparently. It should just authenticate them and sign an assertion to that effect and redirect them back to the external site. If they don't have NTLM they'll be promtped for their domain credentials first.
UPDATE: as noted by #Steve the external site still needs to authenticate external users. Making your external site a SAML SP doesn't solve that. You could have the external website do some built-in authentication or you could have a different SP endpoint (URL) for external users and use another IdP for them.