Based on the research I did, I believe ADFS (2016) is supporting OpenID Connect Session Management. But I could not find the end_session_endpoint of our installed ADFS 2016 server. I found that in Azure (https://login.windows.net/contoso.com/.well-known/openid-configuration) we have this endpoint as https://login.microsoftonline.com/[tenant]/oauth2/v2.0/logout. But unfortunately we don't see a similar endpoint in our installation. We have for example authorisation endpoint, token endpoint, user endpoint etc, but not this one.
Do we have to enable this with a different configuration or ADFS 2016 doesn't support this in the standalone installation ?
Appreciate your help.
I don't think it does and even if it did: the Session Management specification is not finalized (it is an implementer's draft), in fact alternatives have been proposed, and it would be hard to ensure that it works against arbitrary RPs.
Single SignOut is supported in ADFS 2016, make sure you have KB4038801 installed on all the AD FS servers.
For more info, https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-logout-openid-connect
Related
I have the following setup:
-We have a ADFS 4.0 (win 2016) running.
-Customer has ADFS 3.0 (win 2012R2). (configured as claim provider trust with our ADFS).
-The customer ADFS have configured the following claim rules for the relying party trust (on their ADFS):
I have configured the same claim rules for the Application group WEP API application as "Passthrough or filter an incoming claim" adding all scopes.
I am using the openid-connect "Authorization code flow" using something like
https://{sts_token_service}/adfs/oauth2/authorize/?response_type=code&client_id={client_id}&redirect_uri={uri}/&scope=openid+profile+allatclaims+email+user_impersonation&nonce=nonce
AND
https://{sts_token_service}/adfs/oauth2/token/
?grant_type=authorization_code
&code={code}
&resource={resource}
&client_id={client_id}&redirect_uri={uri}
&scope=openid+profile+allatclaims+email+user_impersonation
I am getting a valid access token just fine, that can be used access the protected api, but I really need the claims as well and I only get upn, but not the others.
Any help will be appriciated.
I have exactly the same situation which works.
You need pass-through rules on the CP and on the OIDC RP.
I have a requirement to integrate an ASP.NET web application with active directory - basically they want to be able authenticate and authorize with AD.
I realise this is relatively simple, but what I want to know is how I can simulate the AD for developing and testing against. I don't have AD available to me (right now) and don't cherish the thought of setting it up even if I had hardware available to run it on.
What other options are available to me? I've seen ADAM mentioned in a couple of places but this doesn't seem to provide the federation services I need (and seems a little out dated). Would it be possible to use Azure for this? I want to keep costs (time-wise as well as money) to a minimum.
I have managed to set up an active directory environment suitable for development using a Microsoft Azure VM.
A brief summary of the steps I went through to get this working are below. Although it sounds scary setting up AD and ADFS, the windows server 2012 interface makes it incredibly easier, barring a few gotcha's I mention below - it takes a while for them to install as well.
Create a new azure windows server 2012 VM and add endpoints for http and https.
Install the AD role on the VM
Install the ADFS role on the VM
Create an ASP.NET MVC 4 app (on your dev machine) and verify it is working correctly.
Run the app through IIS (not IIS express - this just makes SSL etc easier).
Ensure the site has a https binding set up
Install the Identity and Access tool for VS2012
Right click your project to select the identity and access tool.
The path to the STS meta document will be https://<your VM url>/FederationMetadata/2007-06/FederationMetadata.xml (you may need to download this file manually if your certificates are self signed).
Back on your VM, in ADFS create a relying party trust for your application.
Run your MVC app again and you should be redirected to your VM for authentication and then back to your app again (but this time using https).
If you are using the default MVC template, in the top right corner assuming you have set up the claims correctly, you should see Hi, <user>#<domain>
The main articles that I followed to achieve this are as follows:
http://blogs.rondewit.com/post/MVC-2b-ADFS-20-Federated-Authentication.aspx
http://garymcallisteronline.blogspot.co.uk/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
Below is a list of gotcha's that I hit (in no particular order).
When setting up the relying party trust enter the data manually and ensure you set the Relying part WS-Federation Passive protocol URL and the relying party trust identifiers correctly. The first is simply the https url that ADFS will redirect back to after authentication has completed - https://localhost for example. The second is an identifier used to identify the application that is trying to authenticate. One of the identifiers entered must match the realm attribute of the wsFederation node in your MVC 4 apps web.config.
When logging in the username should be of the form <domain>\<username>
I couldn't get Windows Authentication to work with any browser other than IE. For this set up to work with Chrome I had to change the order of the local authentication types in the web.config of the adfs/ls application so that forms authentication appeared first. To get to this, open up IIS manager on your VM, expand default web site/adfs/ls, right click ls and select explore.
At the time of writing I haven't been able to login with an AD user I created myself - I've probably just not set it up correctly. When setting this up initially, I'd suggest trying to connect with the admin user you created through the azure portal when you created the VM.
Once I finally managed to authenticate correctly AntiForgeryToken html helper started throwing an exception, talking about missing claims. Ensure that you have added a claim rule to your relying party trust, that sets either the name or name id claim. Then in Application_Start do the following: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name; as explained here.
It is also worth noting that the Identity and Access tool allows you to setup authentication with Azure ACS and more noteworthy, a development STS. For my requirements, I need to be able to integrate with ADFS, but if you're just experimenting with claims based authentication, one of these may be a better option than the process that I have gone through above.
Consider ADFS and ws-federation.
Ws-federation is an enterprise sso protocol that gives you cross domain authentication/authorization in a sso manner. Adfs is a free implementation of the protocol that sits on top of the active directory. It is relatively easy to set up.
But having a client application that expects a ws-federation identity provider, you can substitute the provider with any compliant provider, your own or the identityserver which is another free implementation but can use a membership provider. The completely custom implementation on the other hand would give you a chance to set up and serve an
arbitrary identities.
The is a small learning curve for this approach but benetifs are:
cross domain sso
support for multiple browsers for free (kerberos/ntlm based ad authentication could be unsupported on some browsers)
works in an intranet and the internet
support for advanced scenarios like for example you can set up your cloud Office365 to authenticate against your local adfs
adfs 2.0 is free component dowloadable from msdn
I have been tasked to implement a SSO process for one our internet sites. I have been reading as much as I can to fully understand SSO and SAML so here goes:
I need to forward to a 3rd party's Service Provider (SP-3rd_party) the credentials a user used to login to our site (SP1). Then SP-3rd_party will authenticate those credentials against their own Identity Provider. Then that 3rd party IdP will redirect back to our service with either success or failure.
Our sites are all written in .NET 4.5. It seems that we as SP1 should just authenticate against their IdP and not go thru their Service Provider (SP-3rd_party). Does that make sense? I feel we are making an additional hop that shouldn't be needed but I am fairly new to all this. If anyone can provide guidance that would be great. Thank you!
This use case is commonly referred to as Service Provider Initiated SSO (SP-Init SSO) in SAML 2.0 and is fairly common. You can find a number of resources that outline the flow a little more succinctly -
http://documentation.pingidentity.com/display/PF70/SP-Initiated+SSO--Redirect-POST#SP-InitiatedSSO--Redirect-POST-1070862
https://developers.google.com/google-apps/sso/saml_reference_implementation
Also, see Section 4.1.2 of the SAML 2.0 Tech Overview document - https://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf
HTH -
Ian
We manage a website that runs of the .NET 4 framework and we need to implement SAML 2.0 to support single sign on. We do not wish to run Active Directory federation services as all user accounts are stored in a SQL server. What do I need to consider when developing a single sign on service whereby we are the identity provider?
I work with SiteMinder Federation Services (SMFSS) and Federtation Manager for CA. Are you planning on also doing Authorization for the SP based on Attributes? Do you have an Authorization SSO Solution already? IF so what is it? If it is SiteMinde then the fastes easiest to impliment solution would be SMFSS. Aside from from ServletExec and Java JDK bugs which are pretty much fixed up now I can get customers who have never used Federation up and running in a day for a SAML 2.0 POC. So, if you do have SiteMinder I would give that a try and I am sure you will be quite pleased. If not we also have Federtion Manager which can run as a proxy into your site or not. We have customers who do things such as use the SiteMinder access logs to charge users for access to SP sites a certain charge per access. We have the attribute Authority so that if you want to provide Authorization based on user attributes you can do that. If SMFSS is on the SO side you can just have the attributes stored on the SPO sides session store. Can you tell more about your use case? When SiteMinder was orignally created one of the uses cases was for SSO between different web servers, etc.
Let me know if I can help with any follow up questions and have a splendid day!
Thanks!
Crissy Krueger Stone
CA SiteMinder Support
Based on your initial requirements, you should take a look at PingFederate from Ping Identity [Note: I do work for Ping I'd]. It can support multiple databases and directories simultaneously as well as provide multi-protocol support in both an IDP and SP role. We can also support different development languages you may have beyond. NET.
HTH- Ian
We have ADFS 2.0 running and have federated with various STS.
Is it possible to federate with Windows Live, OpenID and Facebook?
Some of our users already have these types of credentials and it would be a bonus to be able to use them.
If so, what URL would be used for the federation metadata address in the "Add Claims Provider Trust" wizard?
Any other gotchas?
ADFS doesn't natively support the protocols of those IP-STSs (with the possible exception of Windows Live). You'll need to put an FP-STS that understands those protocols (e.g., PingFederate) between ADFS and them.
We have been investigating this question a lot.
It seems that the best setup is to use ACS in combination with AD FS 2.0 as described in this article.
This setup also enables claims transformation, for example, if you want to add the corporate customer number as a claim.
We have not yet seen any examples where you can connect AD FS 2.0 directly to Facebook however.
Yes . there are no direct way to get the claims from ADFS , need to configure the ACS and need to set the ACS as ID providers to ADFS.
But the token validation for ACS is 24 hours at max , so you need to be happy with short-lived token for Social Id providers.