I'm becoming mad trying to set up ADFS authentication for Sharepoint. The error I'm getting is:
Ensure that the SecurityTokenResolver is populated with the required key
The error is thrown by /_trust/default.aspx that is the endpoint where ADFS redirects after successful login and clearly states that the certificate I've used to create New-SPTrustedIdentityTokenIssuer and also imported as SPTrustedRootAuthority for the whole Sharepoint is not trusted by the certificate used by ADFS for Token-Signing and Token-Decrypting mechanism.
I've tried with my own certificates from a CA enroled to AD and with a commercial one. I've verified that thumbrints correspond in both sides, SPTrustedIdentityTokenIssuer/SPTrustedRootAuthority and ADFS side.
Need some help here before going completely crazy.
Many thanks.
Resolved.
The certificate must be exported from ADFS Token-Signing one. This is the one you want to use for the client side. In this case Sharepoint SPTrustedIdentityTokenIssuer.
Related
The case: A client asked for SSO to access their internal SharePoint applications externally (They will add Exchange later on), they do not care if the device is on the domain and they want the experience to be seamless, so anyone with a valid user name and password regardless of whatever device they are using can access the apps.
I have followed the tutorial on WSO2 website to use WSO2 Identity Server 5.3 (passive STS) as an identity provider for SharePoint 2016, and after some tinkering it worked.
https://wso2.com/library/tutorials/2015/05/tutorial-sso-for-microsoft-sharepoint-web-applications-with-wso2-identity-server/
Then I added another application in sharepoint, added it as a second service provider in WSO2 Identity serverand, added the second realm to the sharepoint trusted provider.
Now the 2 applications only work if I start a new session in my browser or clear cookies, after looking into it, when I open the second application in a different tab it is taking the URI of the first application I opened rather than the its own, and it fails as the realm setup in the second service provider does not match the realm for the application in SharePoint.
So here are my questions:
1- Am I doing the SSO using WSO2 incorrectly (Thus the tutorial title is misleading) , and is the passive STS federation , simply that, a federation and not the way to do the SSO in WSO2 Identity Server? If not, could you please tell me what exactly I need to do to fix my issue?
2- If the above is the wrong approach is using SAML Web SSO configuration the right answer? If so, what is the realm that I should use for the sharepoint applications, and is passive STS needed at all in this case?
I am having problems correctly installing the OAuth certificate required for Xero partner integration on IIS 7.5 on Windows Server 2008 R2. There used to be guidance from Xero on this at http://developer.xero.com/documentation/advanced-docs/using-partner-applications-with-iis/ but the page just 404s now.
I've installed the certificate to the Trusted Root Certifications Store as per the prior Xero advice, and my code can retrieve the certificate (using its serial number); but when I try to access the private key, I get a CryptographicException: Keyset does not exist error, which other SO posts suggest is a permissions error (my application runs under a dedicated service account), but all those posts assume the certificate is installed in the personal certificate store - the TRC store does not give me the option of granting permissions to the service accounts or any other account.
I think that page used to give information about installing an Entrust client certificate as partner applications in the past needed to use one.
You don't need to use a client certificate these days and partners should instead direct their traffic to "https://api.xero.com" instead of "https://api-partner.network.xero.com".
You also don't need to install your oAuth certificate as that certificate is used only for signing your requests.
I am developing one asp.net website and I will be hosting the site on windows azure. My requirement is when user access the site like www.xyz.com\admin then live id authentication should happen but when the user access the site www.xyz.com then no need do authentication.
After referring to an MSDN document I come to know about ACS with WIF, so I created the namespace and did so on so on.
But whenever I am accessing the federation URL (https://xyz.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml) I am getting error:
ID:1089 unable to connect the remote server.
I unfortunately deleted the certificate and keys and service identities in windows azure I don't know how to get it back, also I don't how do fulfill my requirement.
If you deleted the certificates and keys they all you need is to just create new one(s). You can either use Self Signed certificates, or use X.509 certificates issued by a trusted Certificate Authority. Once you get your X.509 certificate (it shall include a private key) you can upload it in the ACS management portal (which is locate at https://xyz.accesscontrol.windows.net/):
The FederationMedatadata.xml cannot be generated without the Token Signing certificate.
Or, the easiest for you, would be to just delete that namespace and create a new one.
I'm setting up a server so that only mapped certificates can get to the webservice. It is set to require SSL/Client certificates, anonymous authentication, asp.net impersonation, forms authentication, and windows authentication are all disabled. One-to-one client certificate mapping is enabled, and certs are set up on the box with an appropriate user mapping. When I try to use the webservice, I get 401.2. If I enable anonymous authentication, it works, but I don't want any old cert to be able to access the website.
I have another machine that has anonymous authentication disabled in this configuration, and it works. I'm not sure what the difference is.
I ran into the same problem, but the solution above did not solve my problem. I was configuring IIS Certificate Authentication on a subdirectory of the website, not on the website itself.
So, this is wrong:
And this is correct:
Once I moved the configuration to the root of the website, everything worked perfectly.
I found the solution at http://blogs.msdn.com/b/saurabh_singh/archive/2009/06/13/avoid-this-confusion-around-client-certificate-mapping-in-iis-6-0-7-0.aspx.
Did you issue your client certs from a Certificate Server that the clients/server trust? If you look at the "Enhanced Key Usage" property on the certificates, is "Client Authentication" one of it's properties? In IIS, is the client certificate mapping role installed (see image 1)? did you enable "Client Certificate Mapping" and map the users to the certificate? You need to import all of the client certificates and map them to user accounts here. You can remove all of the other client authentication methods when you have configured that here.
The problem ended up being the software that was calling in, not in the configuration. I'm awarding natemrice the bounty since he put in a good effort to answer what ended up being a non-question.
edit: For more information, it actually ended up being a mismatch between the cert being sent (from the local box) and the cert that was put in the oneToOne mappings. The common name was the same, but the certs were different (likely the first one expired) so the cert simply wasn't authorized.
I'm new to WIF - sorry in advance if my questions seems to be very basic...
I have a 1 WebSite lets say localhost that require username/password authentication. Access to //localhost/ForSecuredClientsOnly should require only client certificate to access the site.
AFAIK client certificates authenticaion is handled by IIS, how should I handle this problem if I want to use STS?
My ideas:
Use 1 STS, set IIS to Accept certificate (not to require) and read certificate in STS and figure out whether user can access the resource.
I was reading through http://msdn.microsoft.com/en-us/library/ff359105(v=PandP.10).aspx and
http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx but when I'm already logged in to //localhost and try to access //localhost/ForSecuredClientsOnly STS thinks that I'm a valid user.
I'm returning new Redirect result from ForSecuredClientsOnly (path from SignInRequestMessage, since user does not belongs to group X) but the realm is always: //localhost/ (probably it's expected behaviour and reason why user is authenticated ...)
Use 2 STSs and move //localhost/ForSecuredClientsOnly to //securedClients.localhost. I don't really like idea of having 2 STSs though
Have 1 STS and create to websites pointing to the same STS. I hope that then in STS I'll see that sign-in request is going from different realm and then perform either username/password of client certificate authentication? I would also prefer not to use that option since it's not ideal if I need to create new website per section of the site that requires different authentication.
Questions:
I would like to make idea number 1 working but how can I pass different realm depending on site subsection, I see that I can set HomeRealm property on SignInRequestMessage but how can I later read it in STS? (User.Identity.IsAuthenticated is always true in STS if I already logged in to //localhost).
Should I be using HomeRealm at all to distinguish between site sections?
If you have ideas what's the best approach to read and validate client certificate in STS please let me know. Currently I'm thinking that I should check whether certificate Thumbnail is one of the certificates that I'm allowing - store collection on client certificate Thumbnails in database?
I appreciate all your input.
I think it will be worth looking at the Starter STS community project at Codeplex.