Is there any chance to avoid ADFS sign in window shown in picture below? I have configured custom STS as claim provider trust on ADFS so I have now two options here. Is there a way to automatically set default value here and skip this page?
Just to note that this isn't the login page - it is the Home Realm Discovery (HRD) page.
If you have:
<persistIdentityProviderInformation enabled="true" lifetimeInDays="30" />
set in your web.config, it will only ask you once and then remember your selection for the "lifetimeInDays" number of days.
You can alter the HRD page - there are many references to this e.g.
Customizing Client Logon and Home Realm Discovery Pages
ADFS 2.0 Home Realm Discovery Deluxe
Home Realm Discovery In WIF And ADFS 2.0 By Query String
Related
I go to my application and check if there is JWT cookie
If it is there, I parse it and start to verify if user have access to my application
If it is not there, I will redirect user to authenticate in FusionAuth
After successful login, user will be redirected back to my application
How do I specify in step 3 fusionauth id of my application?
And how do I specify that I want to redirect to my application after successful login?
I assume that fusionauth is running on fusionauth.mydomain.com and application on myapp.mydomain.com and JWT cookie will be issued in mydomain.com, so it will be visible for both.
Yes, this is possible.
In step 3, you will redirect the browser to the FusionAuth login page. Navigate to Settings --> Applications in the FusionAuth UI and click on the green view button for the application in questio.
This will bring up a dialog which will show integration information (if you're on a recent version of FusionAuth).
You'll see a link something like this:
OAuth IdP login URL: https://fusionauth.mydomain.com/oauth2/authorize?client_id=ee31103f-2fc1-4bb5-ba95-ac543693503e&response_type=code&redirect_uri={your URI here}
The client_id parameter in this case will identify your application to FusionAuth.
And how do I specify that I want to redirect to my application after successful login?
This is configured in FusionAuth as an authorized redirect, and then you specify this same URL when redirecting to FusionAuth to login. Notice the redirect_uri parameter in the example URL above. There is a screenshot of this configuration here: https://fusionauth.io/docs/v1/tech/oauth/overview
I assume that fusionauth is running on fusionauth.mydomain.com and application on myapp.mydomain.com and JWT cookie will be issued in mydomain.com, so it will be visible for both.
FusionAuth does not currently drop cross domain cookies. If you are running FusionAuth at fusionauth.mydomain.com the Cookie will have that same domain and not be visible to myapp.mydomain.com.
If you want to leverage FusionAuth, then you do not need to inspect the cookie on myapp.mydomain.com, you'll simply redirect the user if they are not logged in and then if the user already has a SSO session on FusionAuth, they will be seamlessly redirected back to your application.
You can review our login workflows to identify the one that fits your requirements the best and then follow the recommended workflow. https://fusionauth.io/articles/logins/types-of-logins-authentication-workflows
This appears to be a standard OAuth Authorization Code Grant workflow. We have this workflow and many others documented here:
https://fusionauth.io/articles/logins/types-of-logins-authentication-workflows
My guess is that your specific workflow is likely the Authorization Code Grant for Single-Page Applications using JWTs and Refresh Tokens that is documented here:
https://fusionauth.io/articles/logins/spa/oauth-authorization-code-grant-jwts-refresh-tokens-cookies
The way that this works is that you start the OAuth workflow from your application by redirecting the browser to FusionAuth's /oauth2/authorize endpoint. You will need to supply this information to start the OAuth workflow:
client_id - this can be found under the Application configuration in FusionAuth
response_type - for the Authorization Code grant, this will be code
redirect_uri - this is the location you want the user to return to after they log in with FusionAuth. You must configure this URI in FusionAuth under the Application's OAuth configuration tab.
If you are running FusionAuth 1.6.0 or newer, you can also click the "View" icon for your Application and it will display a pop-up dialog that will contain the OAuth URL. You will still need to specify the redirect_uri though. Here is the documentation page for the Authorize endpoint:
https://fusionauth.io/docs/v1/tech/oauth/endpoints#authorize
Once you have that working, you will need to write the Controller for your redirect_uri. This Controller will take the code from the URL that FusionAuth generates and call the /oauth2/token endpoint. This process will exchange the authorization code for an access token, which is a JWT.
The documentation for the /oauth2/otken endpoint is located there:
https://fusionauth.io/docs/v1/tech/oauth/endpoints#token
This will help you implement your Controller.
Please note I am new to the applications I am mentioning so I might use the terminology incorrectly. I've added a few diagrams to explain myself as best I could.
I am trying to setup a web service authentication policy in APIMAN (which uses Keycloak internally)
So far I know the Identity Provider (OpenAM) I created in Keycloak is configured correctly since it is working on the Login page (see image 1 below)
I have also successfully used an access_token via Keycloak's OpenID API to access a web service; but only if the user credentials are in Keycloak (as oppossed to OpenAM) (see image 2)
What I'd like to achieve is to authenticate this web service client via Keycloak but using the Identity Provider's credentials, but I do not know how to do this or if it is even possible. (see image 3)
Please note I also tried User Federation with the LDAP behind OpenAM and it worked correctly, but I would like to know if there is a way to do it via OpenAM.
The way you used keycloak and openam is quite unusual, however if i understand correctlly your question, you want keycloak to redirect the webservice request to openam, not ldap,
You can either:
configure openam as a identity provider using saml:
Openam would be your source of identity, and keyclaok would be his clients, you can do this by configuring keycloak: identity provider -> saml IDP -> and here you will place openam metadata.
configure openam as OIDC provider:
In keycloak you go to identity providers -> create -> oidc v1 provider -> and you will place your openam info.
As i said, its can be done, but its not the way its suppossed to be, openam and keycloak are both Access management software, they both do exactly the same thing, in your configuration keycloak play a role of an API gateway, which is not exactly what keycloak should be doing, you can get get rid of either one of the solutions, both can provide you the same functionnalities (OIDC, OAuth2, SAML, LDAP, ...)
We have an existing MVC application which is used by multiple customers.
Currently, each customer is given a URL to our application e.g. https://myapp/mycustomername.
When they go their, they are presented with a login screen.
For some customers (not all) we want to implement SSO, and authenticate their users against their active directory, so that they never see the login screen (unless the SSO authentication fails).
Most customers won't be using this functionality.
My first question is: is this do-able? Is it possible to have an MVC application which uses both SSO and forms authentication?
If so, can anyone point me to any links explaining the process?
I've seen some good information, such as this tutorial but I can't find anything that matches my scenario.
Thanks.
This is surely a do-able task.
The steps would be
Identify the tenant name from the URL
Get the Identity Setting
If forms authentication, show them the login page
If SSO enabled, redirect to their ADFS URL
When you onboard your tenant, you will have to maintain the following metadata
TenantName
AuthenticationType : {forms / ADFS}
SSO Url
SSO Federation Metadata URL
etc
We did one such implementation that supports ADFS, Social Logins with Forms Authentication too.
Assumptions:
Client is a Web application (ASP.NET) configured for STS Passive Issue
Server is a MVC Application with 2 services (1. Issues a token and other gets metadata)
Server on the other hand configured for Forms authentication and should redirect to Login page if unauthenticated access is made.
Workflow:
end user tries to load client.
It contact the STS by redirecting to the STS server.
The server is configured with Forms authentication with a redirect URL.
But Server does not redirect to login page. instead it allows to call the Issue end point.
I tried to restrict via authorization tag in web.config. Also, i tried location tag to set authorization explicitly. But it still allows the call.
i referred many blogs
How to: Enable the WCF Authentication Service
How to: Customize User Login When Using the WCF Authentication Service
But no luck.
This is easy to achieve with ADFS. Use the following steps if ADFS is your STS:
Navigate to the folder where ADFS web application is located (normally C:\inetpub\adfs\ls)
Make a copy of the current web.config for safety
Open web.config in notepad
Locate
In , change the order of authentication to assure that it lists Forms Authentication first
The order must look like this:
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
Save the changes (you do not need to restart ADFS)
Navigate to your application and click on Login. Instead of sending the login request to ADFS, a page containing a login dialog will pop up. Please enter your credential and click ok. Then, you will get the same result as above.
Reference articles:
Claims Aware MVC4 App using WIF Identity and Access tool in .Net 4.5 Part I
Claims Aware MVC4 App using WIF Identity and Access tool in .Net 4.5 Part II
Configuration is: ADFS 2.0 as IdP (both WS-Federation and SAML 2.0 are supported), ASP.NET app as Service Provider. When SPS requests ADFS with WS-Federation standard (WIF used) it lets me login to ADFS automatically with no login pop-up window even if new session started, so that Kerberos token does its job well as expected. However in case of SAML 2.0 (ComponentSpace.SAML.2 lib is used) every time I open IE9 and being redirected to ADFS, I'm asked to enter my windows domain credentials in a standard small pop-up login window. Is any SAML 2.0 parameter or other technique letting me to get rid of this window like in the WS-Fed case? Thanks
adfsserver.us.mycompanyname.com/adfs/ls is in the Internet zone and the automatic login will not happen.
adfsserver/adfs/ls is in your Intranet zone in IE and will log in automatically.
You could add adfsserver.us.mycompanyname.com to your trusted (or Intranet zone) sites list and you should be not be prompted for credentials.
It's not an answer, it's rather update to my question, but it's important and I decided to put it as an answer to attract more attention to it. What I've figured out playing with the SAML parameters for few days is that it seems to be not depend on protocol (WS-Federation/SAML2). What it actually depends on is long/short adfs server domain name, so that authentication request like https://adfsserver.us.mycompanyname.com/adfs/ls makes this window appear, while https://adfsserver/adfs/ls does not. However I can not use short domain name for SAML 2.0, I'm getting error in the case: "MSIS1006: The configured passive endpoint 'https://adfsserver.us.mycompanyname.com/adfs/ls/' is not a prefix of the incoming SAML message Destination URI 'https://adfsserver/adfs/ls/'". BTW, we use SSO in our local intranet only, so I do not know why this exception occures. Any workaround?
You can change passive endpoint server following steps mentioned below:
http://breakingdevelopment.blogspot.in/2012/12/adfs-msis1006-i-am-working-on-sso.html
Open ADFS 2.0 Service Manager
Select "Edit Federation Service Properties..." from the top right corner. This brings up the Federation Service Properties window
Change the Federation Service Identifier to match the Identity Provider URL (IdPURL) passed from your SSO application.
Try: urn:federation:authentication:windows instead of: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
in this part of the SAML 2.0 authentication request:
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</saml:AuthnContextClassRef>