What is the best way to customize ADFS to use a specific, configurable home realm if one was not provided?
My current method is to perform an HTTP redirect from the ADFS WebForms aspx file, but that seems a bit hackish.
I don't want my Relying Parties to be concerned with the home realms.
I think that a good approach would be to add a few lines within the ADFS HomeRealmDiscovery page in order to read the "DefaultHomeRealm" setting from the ADFS web.config file.
Steps
Go to C:\inetpub\adfs\ls
Open the HomeRealmDiscovery.aspx.cs
In the Page_Init method, add something like:
if (ConfigurationManager.AppSettings["DefaultHomeRealm"] != null)
{
SelectHomeRealm(ConfigurationManager.AppSettings["DefaultHomeRealm"]);
}
Open the web.config file
On the appSettings section, add:
add key="DefaultHomeRealm" value="Default ADFS Federation Service Identifier"
Do not forget to replace the service URI that you want to be defaulted.
For more information you can check:
SelectHomeRealm method
ADFS pages customization
I have successfully used this approach.
I hope it helps :)
Seba
Have a look at:
Windows Identity Foundation (WIF): How to Utilize the WS-Federation WHR Parameter to Bypass Home Realm Discovery (HRD).
The WS-Federation passive WHR parameter is used to bypass home realm discovery (HRD)
Related
I'm facing the same issue as the one posted at (How to get authorize code to dismiss login page with oauth2 wso2 identity server)
I tried to follow the solution instructions, but in my case, the drop-down menu under "Request Path Authentication Configuration" is empty; no options listed.
I checked the application-authentication.xml file under /opt/wso2am-4.1.0/repository/conf/identity and I have this:
I'll apprecitate any support you can provide. Thanks. Daniel
Just to close this thread, and as I was not able to get a solution, I solved it by running an instnace of the WSO2 Identity Server and handle the security through this product, instead of using the IS features the API manager has embedded. cheers!
I am building a multi-tenant asp.net core app based where tenants are selected by host names. So tenant1.example.com, tenant2.example.com, ..., and so on.
Also, I'm using Google authentication using the default Google auth handler in asp.net core services.AddAuthentication(...).AddGoogle(...)
It's working great, except that Google doesn't support wildcard callback URLs. So every time I add a new tenant, I have to configure my Google app with a new callback URL to reflect the new host: tenant1.example.com/signin-google, tenant2.example.com, ..., and so on.
The asp.net core Google handler lets you specify the callback path, but not the URL. I plan to overwrite the handler to have the callback URL always go to a redirector url hosted on the naked domain, example.com/redirect-google (I'll be careful about open redirects), and have that redirect to the appropriate sub-domain to complete the authentication.
Has anyone done this before? Anyone see a problem with this approach?
You are right that the authentication system does not allow you to further modify the host for the OAuth redirect URI. This is mostly done to make the system host name agnostic, which is a common pattern that is used throughout the framework (basically every URL generation is based on the current context).
As a workaround, what you could do is set up your own authentication handler for the Google scheme. You can actually inherit from the GoogleHandler and override the BuildChallengeUrl. That method is called to actually build the challenge URI of the authentication provider. It gets passed the redirectUrl which is the callback route of the OAuthHandler (the thing you cannot change the host name of).
So by overriding the method, you can simply change the redirectUrl that gets passed and replace it with the general URL that you want to use.
protected override string BuildChallengeUrl(AuthenticationProperties properties, string redirectUri)
{
return base.BuildChallengeUrl(properties, "https://example.com/redirect-google");
}
When you do that, you will just have to replace the GoogleHandler in the DI config:
services.AddTransient<GoogleHandler, ReplacedGoogleHandler>();
We are trying to configure and develop a solution to properly brand the login site accordingly to where the user is coming from. The users are coming from relying parties, but they all use the same login site (STS).
Is there any way I can set a property from the RP that will be accessible from the STS? The wtrealm property is changed once it passes through the ADFS webservice. The RU parameter of the wctx is relative to the site it is redirected to, so it wont help.
I just need the STS to be aware of where the user is coming from, that way I add the necessary style sheets necessary.
Ended up baking an additional parameter into the query string via the ADFS webservice. Just edited the global.asax file and added the necessary parameter from there, then told the STS to pick up on this variable.
I have tried searching for this and can't find anything.
I want users to have a true SSO experience. Meaning they login to their computer and when they hit a web app that we have set up trust with in ADFS they are taken straight to that website. Right now no matter what they are taken to the ADFS forms login page. We only want the forms login page to appear if the user is not already connected to the network. Otherwise, ADFS should recoginize that the user is on the network and use the windows authentication.
What do I have to change in ADFS to make this happen?
In ADFS web.config, what order do you have for:
<localAuthenticationTypes>
<add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>
Is Forms on top?
Are these users on the internet or intranet?
Do you use an ADFS proxy?
One option is to add a handler for the RedirectingToIdentityProvider event by placing the code just below this paragraph in your global.asax. This gives you a chance to jump in before the browser is redirected to ADFS and modify what the request (query string) looks like. You can do this to specify authentication types, or home realms (if you have multiple federations and want to skip HRD), and probably a lot of other stuff I don't know about.
void Application_Init()
{
FederatedAuthentication.WSFederationAuthenticationModule.RedirectingToIdentityProvider += new EventHandler<RedirectingToIdentityProviderEventArgs>(WSFederationAuthentication_RedirectingToIdentityProvider);
}
Then you would add code to your handler that might look something like this:
void WSFederationAuthentication_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e)
{
WSFederationAuthenticationModule instance = FederatedAuthentication.WSFederationAuthenticationModule;
SignInRequestMessage request = instance.CreateSignInRequest(Guid.NewGuid().ToString(), instance.Realm, true);
request.AuthenticationType = "urn:federation:authentication:windows";
Response.Redirect(request.WriteQueryString());
}
When you set the request.AuthenticationType to that value, you're telling ADFS that you want to do windows (integrated) authentication. This was all that was required for me to get it to work. I didn't have to bother with switching the order of the authentication types in the web.config as nzpcmad suggested.
Also, for this to work, IIS and your web browser are working some magic outside of AD FS and your relying party, so in IE your users have to go to tools > Internet Options > Security and add the site to your Local Intranet sites. There's probably a way to push this out with group policies or something, but that's another question. Anyway, now that I think of it, this may be the only step you're missing.
Using a provided username, password, and domain name, how can I retrieve a boolean value indicating if a user has successfully authenticated with a primary domain controller? Authentication should be performed using the Kerberos protocol for windows domain controllers. Thanks in advance, Dan
There's a free implementation of a windows-only JAAS login module and of an SSO Negotiate (Kerberos/NTLM) authenticator: Waffle.
You need to either write your own or use third party Authentication Module for that. When I was doing this, there was nothing available from JDK, so I used this tool. Note that it's GPL, but you can learn from there. You will have to create conf. file describing your authentication module and feed it into your JVM with java.security.auth.login.config property (e.g. using -D, or either way). In case of Tagish it looks something like this:
NTLogin
{
com.tagish.auth.win32.NTSystemLogin required returnNames=true returnSIDs=false defaultDomain="domain";
};
Another thing you will need is to specify kerberos configuration file via java.security.krb5.conf property. I don't have the details of this file handy, but you can easily find it on the net -- google about for krb5.conf. Settings in this file will have to match your windows domain and other windows specific settings.
It's a bit tricky to configure, but for me it worked very well, pretty robust.