I am attempting to set up a test configuration for IdentityProvider(IP-STS)-Initiated SSO using ADFS 2.0 as my RP STS and a Active Directory identity provider. Here is my set up:
Identity Provider - Domain Active Directy
RP-STS - ADFS 2.0 instance with an RP trust relationship with my asp.net application.
RP Application - ASP.NET web application (WIF) with an STS reference to my ADFS 2.0 STS.
I know I need to create some kind of trust between ADFS and my IP but I don't know what that might be. My issue is I can't find any good resources for instructions on how to do this. Most of what I find assumes that ADFS is also the Identity Provider and is configured. I am not finding the right resources
please any one help me with right example.
Thanks,
sampath.
When you say "Identity Provider - Domain Active Directory", what IP are you using?
AD is not an IP?
ADFS (which uses AD as its repository) is.
When you install ADFS it "binds" to the AD DC in the domain - that's the trust relationship. You don't need to do anything explicit.
If you indeed have another IP, then you set up a CP / RP relationship between the two IP with the normal metadata exchange.
Yes, AD is an IP(Identity Provider).
I've Installed ADFS in one machine(VM), and my Identity Provider(Ipd) is in another VM.
Now i want to establish trust relationship between these two.
you are saying When you install ADFS it "binds" to the AD DC in the domain - that's the trust relationship means I need to setup ADFS and AD DC in the same machine(VM)?
i have another IP, then how to set up a RP relationship between the two IPs with the normal metadata exchange?
i've added the AD DC as relying party trust in adfs. but getting the following error
*HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Requested URL
Physical Path C:\inetpub\wwwroot\ClaimsApp_STS\
Logon Method Anonymous
Logon User Anonymous*
Thanks,
Sampath.
Related
I have successfully configured a SAML 2.0 Identity provider in a separate Weblogic domain
We have an ADF application deployed in Weblogic in another domain with non-SAML form-based authentication (ReadOnlySQLAuthenticator is used to verify credentials)
I want to configure the second domain as a Service Provider (to enable the existing application to login with the Identity provider.
I did the folowing:
Configure a SAML 2.0 Identity Asserter
Enable the Service Provider in the federated services for the server
Add and enable the "service provider partners" and exchange metadata on both IDP and SP side
Configure the "redirect URI" on the SP side
Add the SAML 2.0 Authenticator (the documentation doesn't mention this, but some blogs do)
This should be enough to make the SSO work, but it doesn't.
opening the application doesn't trigger a redirect to the IDP (even when the URL is configured in the provider partner config)
after logging into the application, other applications still have to log in with the IDP (SSO doesn't work)
The "other application" is the Spring SAML sample application and I verified that SSO works with 2 different instances of that app (which means the IDP side should be configured correctly).
We've had some Oracle experts come over to our company to solve various issues.
In the end even they could't help with this and suggested that SAML support may not really work that well.
They suggested that we try to use Oracle Access Manager, that's supposed to support both OAUTH and SAML. We didn't get to that yet and maybe never will.
Still if you need SSO in Weblogic, you could give it a go.
We are trying to federate our application, so that our customers can gain to our application using their respective corporate identities (Ping Identity or their ADFS server).
The web application is non-claims aware and we are trying to find out a solution to federate it without changing the code.
I built an ADFS 3.0 environment with windows server 2012 R2 simulating a future scenario, following my lab environment:
Our side:
1 Active Directory server (domainB)
1 IIS8 web server with our non-claims aware applications (Windows Integrated Authentication supported by Kerberos mechanism) joined on domainB
1 ADFS 3.0 server (service provider) joined on domainB
1 WAP server joined on domainB
Customer side:
1 Active Directory (domainA)
1 ADFS 3.0 server (identity provider) joined on domainA
Application users:
domainB\user1
domainA\user2
I followed these steps to build my lab environment:
Installation and configuration of ADFS 3.0 on domainB
Installation and configuration of WAP server on domainB
Publish ADFS 3.0 on WAP server on domainB
Create a Non-claims aware Relying party Trust pointing the application on ADFS 3.0 on domainB
Publish the Non-claims aware to WAP on domainB
Installation and configuration of ADFS 3.0 on domainA
Trust ADFS 3.0 on domainB with ADFS 3.0 on domainB
Edit claim rules on each federate server
The “domainB\user1” has no problem to access to the application, in my WAP server there are the following events:
Web Application Proxy successfully retrieved a Kerberos ticket on behalf of the user.
Web Application Proxy received an HTTP request with a valid edge token.
The “domainA\user2” cannot access and appears a server error on the screen and in the WAP Event Viewer there are the following errors:
Warning: EventID 13019
Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: The user name or password is incorrect.
(0x8007052e).
Error: EventID 12027
Web Application Proxy encountered an unexpected error while processing the request.
Error: The user name or password is incorrect.
(0x8007052e).
Seems to be an issue with the Kerberos authentication but the domainB\user1 has no problem to access to the application.
Need to understand:
Where is the issue?
Accessing to the non-claims aware applications are supported by only the users members of the same domain of the web application server
I’m spending many days to find out the cause.
Appreciate any direction here.
Thanks
Given that "non claims-aware" apps make WAP+ADFS use WIA, and WIA requires Kerberos, you need to issue a Kerberos token on WAP-B for "domainA\user2", this in turn requires setting domain/forest trusts between domainA and domainB (domainB should trust domainA, at least). I don't see domain-level trusts present, only ADFS-level, therefore Kerberos domain domainB says "unknown user domainA\user2". Check if enabling trusts between domainA and domainB would resolve the issue.
You need Kerberos shadow principals in domain B for users in domain A who will be accessing the application. It is a similar situation to azure B2B guest users accessing an application through azure application proxy. This is a walkthrough for setting that up with sync from Azure (https://learn.microsoft.com/en-us/azure/active-directory/b2b/hybrid-cloud-to-on-premises). It would be similar for your case, except you'd need to replicate the users from their directory.
I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?
I have web app which uses WIF/ADFS claim fo ruathentication, i have set up one adfs and AD for that.
Now my need is i want to redirect and levarage client specific ADFS & AD for authentication.
App->Local ADFS->Client-1 ADFS->client -1 AD
App->Local ADFS->Client-2 ADFS->client -2 AD
so i want to do configuration for that client specific redirection in my Local ADFS, is it possible?
If I understand correctly you'll have an ADFS Federation Provider (FP) Issuer in your organization and your clients will have an ADFS (or other) Identity Provider (IdP) Issuer on their side.
To do this you would setup 2 Claims Provider Trusts (CPT) in your ADFS, one for Client1 and another for Client2. When you start the new CPT wizard, you may be able to configure these using metadata provided by your clients ADFS (e.g. https://fs.client1.com/federationmetadata/2007-06/federationmetadata.xml). Your clients will then also need to configure your organization as a Relying Party Trust (RPT) in their ADFS. If your metadata is available to them via a URL, they should be able to use the new RPT wizard in ADFS and configure their RPT for your organization with something like https://fs.myorg.com/federationmetadata/2007-06/federationmetadata.xml. Then, claims rules should be configured in these RPT's at your clients for claims to send to your organization and your CPT's for your clients should be configured to process the received claims from the clients.
I have the following scenario:
Sharepoint 2010 with Claims based authentication web application.
ADFS 2.0 which has configured Claims provider trust to the ThinkTecture IdentityServer.
ThinkTecture IdentityServer which has configured ADFS 2.0 as a relying party.
Sharepoint 2010 has SPTrustedIdentityTokenIssuer configured pointing to ADFS 2.0.
Now when I'm loging to the Sharepoint, I'm redirected to the ADFS 2.0 Home Realm page, when I choose Identity Provider. Then I'm redirected to the ThinkTecture IdentityServer. Then I'm logged with my credentials from IdentityServer and I'm redirected back to the ADFS and then to the Sharepoint. The problem is, that sharepoint show error message. I'am adding log records from sharepoint:
Authenticated with login provider. Validating request security token.
Trusted login provider 'SAML2 Provider' is not sending configured input identity claim type 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'
SPSecurityTokenService.Issue() failed: System.ServiceModel.FaultException: The trusted login provider did not supply a token accepted by this farm.
at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.SPRequestInfo.ValidateTrustedLoginRequest()
Access Denied: Authentication is required.
I was find out, that the token returned from Identity Server to ADFS contains emailaddress claim, but the token returned from ADFS to SP does not. It is a strange, because I have ADFS configured to support emailaddress to pass through for all claims
(in Claims provider trust for identity server). Do I need to setup adfs somewhere else? I am newbie in adfs.
What I want to achieve is to forward my request through the ADFS to the IdentityProvider (in this case ThinkTecture IdentityServer) and to get back the token from IdentityProvider. ThinkTecture IdentityServer is only in my test environment in the real environment it will replaced by Oracle Identity Federation.
The target problem is to integrate Sharepoint 2010 with the Oracle Identity Federation. But the problem is, that the Sharepoint doesn't support SAML 2 protocol which OIF will provides as exclusive endpoint binding. So I'm trying to hack it with the ADFS (as a somethinkg like proxy) which will communicate with Sharepoint based on the SAML 1.1 on one side and with the OIF based on the SAML 2 on other side.
This is the following extract from IdP metadata:
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">...
So I have no option to use WS-Federation.
I will appreciate advise if this is a good way how to achieve the required behaviour.
thanks
So your path is SP -> ADFS -> IdentityServer?
The problem is that the email address is not being passed through. So you have to set up IdentityServer to generate the email address claim and you have to setup ADFS to pass through all claims. Then configure SP to accept email address as a claim (using the SP Powershell commands).
Add: You need to create pass through claim rules for the email claim in ADFS - both for the claims provider trust and the relying party trust.
OIF supports WS-Federation - refer ORACLE IDENTITY FEDERATION 11g R2 - so no problem to federate OIF with SP.