I'm using adal.js on my react app (using react-adal wrapper). I configured my app to work with my ADFS 2016 server (on premise), and the authentication process works fine, but after the ADFS SSO cookie expired, when the client sends the renew token request (in an hidden iframe), the browser shows in the console the following error: refuse to display 'https://myadfs/adfs/ls/SAMLRequest=...' in a new frame because it set 'X-frame-options' to deny.
In order to reauthenticate, the user needs to refresh the page (F5).
Is there any solution / workaround to this problem?
ADFS <= 2016 does not allow iFrame based logins for any interactive authentication for security reasons. This would have worked if the user did not need to perform an interactive sign-in (either SSO cookie or WIA).
The right pattern (since you are on 2016) is to use OIDC flows to log into the application and use the refresh token to get new access tokens.
Even here you need to handle the refresh token expired case where you will need to store your app context locally (cookie or local cache) and enable a full redirect to ADFS.
ADFS 2019 now has the option where an admin can configure options for which host(s) they allow iFrames by controlling the headers.
Thanks //Sam (Twitter: #MrADFS)
Like I explained in this similar question, the commandlet "Set-AdfsResponseHeaders" is also supported on ADFS 2016 since a recent MS update (about May 2019) :
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
Howeber, I agree with SamuelD MSFT on the fact that it's not a good practice any more to use iFrame integration nowadays.
Related
We are currently having problem allowing a user to a specific URL without logging in in Azure AD authentication.
We are successful in getting token and using it for our API's. But we are currently having problem allowing user to access a URL without them logging in.
What we have tried so far was this links
https://learn.microsoft.com/en-us/graph/auth-v2-service
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Thanks!
In your second link, in the azure portal-> your app service -> authentication and authorization screen, make sure the "action to take when request is not authenticated" is set to allow anonymous. if you set that option to "log in with active directory" that forces authentication on every page no matter what. And ensure in your code that page doesn't require login eg.remove the [authorize] tag.
I am following this guide (https://learn.microsoft.com/en-us/skype-sdk/ucwa/authenticationusingazuread) in order to access Skype for Business. Everything goes fine till the last part but let's do step by step. I am building my .net console application to do this but in order to explain you properly the problem I am having I will show you directly the http calls through Insomnia (software used to make http calls).
Step 1:
GET request towards https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root
I hit 200 and as answer I receive this:
Step 2:
I use the user link.
So I send an http request to https://webdir1e.online.lync.com/Autodiscover/AutodiscoverService.svc/root/oauth/user and I get a 401 Unauthorized (everything still correct).
In the header of the answer it points me to the Identity Provider to ask for authorization (authorization_uri)
Step 3: I use that link to authorize my app, which has its own client_Id (that I hide in the following screenshot).
This is how I compose the call:
If I send this http request I get redirected to the page where it asks my personal login and by inserting my credentials I succesfully login and hit 404, where in the answer I receive back my access token.
Step 5: I use the access token towards the same AutodiscoverService link of step 1. This is to register my application. I hit 200 and I receive back the link to access Skype for Business.
Finally (and this is where things go wrong) I send a POST request towards the applications link with the Bearer token, and I receive a 403 Forbidden. I think I am following correctly the guide but I can't figure out why I can access the resource at the last step.
EDIT:
The permissions are granted. I hide the name since it contains the name of my company. But it is the same of the domain of my login.
So the token you generated authorizes you to access resources at https://webdir1e.online.lync.com which you've done to fetch a new set of resources including the "application" resouce which is on a DIFFERENT host: https://webpooldb41e14.infra.lync.com.
You actually have to get another OAuth token now which authorizes you for the application resource and then you can POST to that to generate your session in UCWA.
As a side note... If you've defined your own single-tenant application in Azure that has been granted rights to SkypeForBusinessOnline then I think you should be targeting authorization and authentication endpoints of the form:
https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token
Also I should add, if you're trying to write a trusted secure client that users in your company will use I would suggest looking up the Resource Owner Password Credentials auth flow. It allows you to directly hit the token endpoint I mentioned above and exchange username/password credentials for an access token. Then you can manage auto-discovery and application creation easily under the hood without getting re-directed back and forth to Azure.
https://learn.microsoft.com/mt-mt/azure/active-directory/develop/v2-oauth-ropc
When using the Postman Chrome App with the Interceptor extension it's easy to reuse the browser's cookies in order to log into an app and then call the services within.
Since moving to the Postman standalone app, this process has become somewhat manual. After logging in from the browser, I have to access the JSESSIONID cookie in the developer tools and copy its value over to postman.
When my session expires I need to repeat the process.
I would like to automate this synchronization or at least understand how I could obtain the new authenticated value in postman. It's important to note that none of the authentication mechanisms available in Postman work with my app which is why the manual login in the browser is necessary.
You can get JSESSIONID cookie in Postman Standalone in similar way your browser do it - by send proper requests (probably POST "login" request with user credentials) to server
This case is very much similar to question by Wiktor Zychla, see How to set the timeout properly when federating with the ADFS 2.0
We are experiencing the same behavior, ADFS happily redirects the user back to Sharepoint site and FedAuth cookie is recreated, even though ADFS should prompt for credentials - we want the user to reauthenticate after some period of idle time. Basically it looks like the session is always sliding.
We have disabled persistent cookies, so the FedAuth cookie is removed when session is ended by closing the browser, so the user is forced to reauthenticate after all browser windows are closed and a new session is started, so that works.
As far as I understand the Web SSO lifetime setting in ADFS Snap-in controls the time after which the user should need to re-authenticate on AD FS (enter his credentials again). Tokenlifetime and LogonTokenCacheExpirationWindow together control, when Sharepoint should redirect back to AD FS to in order to renew FedAuth cookie.
Following is a quote from http://msdn.microsoft.com/en-us/library/hh446526.aspx :
To force users to re-enter their credentials whenever they are redirected back to ADFS, you should set the web SSO lifetime in ADFS to be less than or equal to SAMLtokenlifetime minus the value of LogonTokenCacheExpirationWindow.
So, we have done following:
1. Setting the lifetime of SAML token
Add-PSSnapin Microsoft.ADFS.PowerShell
Set-AdfsRelyingPartyTrust –TargetName "[ourrelayingpartytrustreference]" –TokenLifeTime 7
2. Setting LogonTokenCacheExpirationWindow (and disabling persistent cookies)
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.LogonTokenCacheExpirationWindow = (New-Timespan -Minutes 1)
$sts.Update()
iisreset
3. Adjusted Web SSO lifetime: 5 minutes in AD FS 2.0 Management console snapin (running Get-ADFSProperties in Powershell correctly returns SsoLifetime: 5)
Thus the expected outcome is:
User starts a fresh new session, requests the web site
Browser is redirected to AD FS, user enter credentials, and browser is redirected back to Sharepoint site, FedAuth cookie is generated
User remains idle for 10 minutes (to make sure that session sliding period has passed)
User requests another page in Sharepoint, browser is redirected to AD FS
Since Web SSO lifetime was 5 minutes, and it was, as in msdn documentation instructs, less than SAMLtokenlifetime minus the value
of LogonTokenCacheExpirationWindow (SAMLtokenlifetime -
LogontokenCacheExpirationWindow = 6 minutes), AD FS prompts the user
for credentials, user enters credentials, and browser is redirected
to Sharepoint page requested and FedAuth cookie is recreated.
Current actual behavior (steps 1-4 similar):
(5.) AD FS does not prompt for credentials, browser is redirected to Sharepoint page and FedAuth cookie is recreated.
So - for us it looks like AD FS session never expires, no matter what we do.
If we create a false configuration of setting LogonTokenCacheExpirationWindow value higher than SAMLtokenlifetime (e.g. LogonTokecacheExpirationWindow = 8 and SAMLtokenlifetime = 7), we get the expected behavior of loop between Sharepoint and AD FS.
We are desperately seeking for a solution to properly expire the session, if user has remained idle for some period of time.
We also tried following configuration change (as per the guidance at http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/802b1bb6-cda3-4470-a0d1-ee709d5c4b7c/):
Set-ADFSProperties -SsoLifetime 1
Set-ADFSProperties -ReplayCacheExpirationInterval 1
Set-ADFSProperties -SamlMessageDeliveryWindow 1
No Global.asax changes yet made.
As far as I understand, we have configured everything according to the documentation, however we cannot force the user to reauthenticate. Any help pointing out the error in configuration is appreciated.
Apologies if you have already done this, but be sure you have restarted AD FS after making the websso changes. We did not get our expected results until we restarted the services. Also, if you have a proxy, may want to restart that as well.
Do you have any pieces of infrastructure that are rewriting the cookies?
I have started maintain a number of websites that are all authenticated using openam SSO. However when one of our users sets a persistant cookie (DProPCookie) it doesn't always work.
Repro scenario is:
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Go to site B, user is presented a login page (they should be automatically logged in).
After step 3, if I delete the iPlanetDirectoryPro cookie from my browser I can login to site B fine (using the persistant cookie). It seems that the iPlanetDirectoryPro cookie generated from Site A when the DProPCookie is set doesn't work on Site B.
Note that I have tried with various permutations of Site A and B and the scenario is the same in each case.
I'm quite new to openam so any hints as to how to debug this would be great or if I'm missing something obviously going wrong please do let me know.
Thanks in advance.
EDIT:
I have subsequently discovered that the iPlanetDirectoryPro cookie returned when authenticating using the DProPCookie isn't working. So thus has nothing to do with cross domain.
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Delete all cookies except iPlanetDirectoryPro cookie
Refresh page - asked to login
If I repeat the test but with the iPlanetDirectoryPro cookie generated by a normal login then when I refresh the page, I automatically get authenticated. (I have changed the title of the question to reflect this).
FURTHER EDIT:
Turned up debugging - am seeing this exception in the logs:
IdName is :null
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
orgName is :xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity() from IdUtils Name: null Org: xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity: Got IdRepoException while getting Identity from IdUtils: Illegal universal identifier null.
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
isLockedOut:Exception :
java.lang.NullPointerException
at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:585)
at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:296)
at com.sun.identity.authentication.service.AuthD.getIdentity(AuthD.java:1453)
at com.sun.identity.authentication.service.AMAccountLockout.isMemoryLockout(AMAccountLockout.java:297)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:281)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:264)
at com.sun.identity.authentication.service.AMLoginContext.processPCookieMode(AMLoginContext.java:1919)
at com.sun.identity.authentication.service.AMLoginContext.processIndexType(AMLoginContext.java:1846)
A quick scan through the openam code - it appears that we are not getting a username here in AMAccountLockout.java:264:
public boolean isLockedOut() {
// has this user been locked out.
String userDN = loginState.getUserToken();
return isLockedOut(userDN);
}
Persistent Cookie mode has changed in OpenAM ... DProCookie is actually not used anymore.
Posssibly you're running 'restricted token mode' AKA 'cookie anti-hijack mode' and CDCServlet does not issue a proper authentication assertion
Could be that you are running into https://bugster.forgerock.org/jira/browse/OPENAM-1002 ?
Also it could be a problem with your cookie domains, maybe site B redirects to a different domain where DProPCookie is not visible?
Ultimately we discovered that the problem was that the SSO cookie generated by the persistant cookie had no authention modules - and therefore the authentication level was set to Integer.MIN_VALUE;.
In our situation we made a slightly hacky fix to force this to be 0 instead, which fixes up the problem.
I presume the correct thing to do would be to either have a seperate authentication module for persistant cookie logins or to store the authenticating module in the SSO cookie generated by the Persistant cookie.