I recently configured OpenAm (v13.0) following this vendor documentaion https://backstage.forgerock.com/docs/openam/13/getting-started. My user agent url is A) http://www.example.com:8000/ and my OpenAm url is B) http://openam.example.com:9090/openam. When I access my agent url, A, my OpenAm web Agent successfully redirect to my OpenAm url, B, as it supposes work.
However when tries to login as user 'demo' and password 'changeit' as instructed in the documentaion, the page hangs and it repeated try to the console url in rapid successions as shown in the following image.
My hunch is, user agent is working fine but the fault must be with some configuration of the OpenAm console. Can you suggest what needs to changed in OpenAm console?
Thanks..
Fixed. I have made a mistake while configuring OpenAm. It is imperative to use the URL, 'http://openam.example.com:9090/openam/'. My mistake was, I've configured OpenAm in the URL http://localhost:9090/openam/.
This is emphasised in the documenation, under the point, 1.4.3. Here is the link,
https://backstage.forgerock.com/docs/openam/13/getting-started#install-openam
Looks like it is very useful for newbies when they're configuring OpenAm.
Related
I have a simple Intranet Website that is just a few HTML pages with a little JavaScript and CSS.
If Allow Anonymous is ON, everyone can see it. It works.
In IIS, I turn on Basic Authentication and it only partially works as expected.
The company only allows IE and Edge installed on Windows 10 PCs for now.
Specific users have been added to that server running IIS.
In IE when users go to the website now, they are prompted for their username and password. Then the website loads.
However, in Edge, the users are never prompted for the their username and password. A 401 errors loads instead.
I have already tried putting the username and password in the URL like so: https://username:password#URL but that did not work.
I want the same or similar behavior that works in IE for Edge.
I assume you're using Edge Chromium browser, correct me if I'm wrong. The issue might be related with this policy: AuthSchemes.
You can visit edge://policy in Edge and check if it has an AuthSchemes policy set. The policy can be used to disable Basic Authentication. If your browser has this policy set, you need to enable 'basic' value in the policy.
I don't have this policy set and I visit the test page https://jigsaw.w3.org/HTTP/Basic/, the Basic Authentication works well in Edge.
You can also refer to this thread and this thread which have similar issues.
I'm attempting to run the project located at https://github.com/docusign/eg-03-csharp-auth-code-grant-core. I've followed all of the prerequisite steps listed in their read me file, have a newly generated Integration Key and Secret Key, and when I build the project in visual studio it runs without errors.
The problem is, whenever I try to sample links it redirects me to a docusign authorization page and when I put in my credentials it just gives me the message "The redirect URI is not registered properly with DocuSign".
I've gone to the admin portion of my developer sandbox and added the URL my project is running on http://localhost:8080. I also added in a second URL for where the example code should bring me http://localhost:8080/dsReturn, but I keep getting the same issue and I'm having trouble finding help online.
Could anyone help me with this? What else do I need to change?
The project runs on the following URL/port:this is the port the base project runs on
If your application is running on http://localhost:8080, the Redirect URI you register in DocuSign should be http://localhost:8080/ds/callback.
Note that the redirect URI is a specific landing page within the project, not the base domain.
Make sure that the URLs are registered for the correct integration key (clientId) you may have a mismatch between the IK you use in your code and the one you used to configure the redirect URI.
It take 2-5 minutes for updates you make to be reflected, make sure to wait a few minutes and try again.
URL must match exactly, http or https doesn't match
Confirm your port #. 8080 is not usually what IIS express is using.
i am running the DOCUSIGN example code "eg-03-node-auth-code-grant" to check how embedded signing works(at https://localhost:5000). So after the signing is complete i would want it to return to another app. I have my other app running at localhost:8080.
In the Docusign developer sandbox account, i have added "https://localhost:8080/ds/callback" in the list of redirect URLs.
When i test the embedded signing code now, it gives me an error saying "Redirect URI is not registered properly with docusign"
What I ideally want is to build a separate docusign app for a consent process. once the consent is done, it goes to my other application to complete the rest of the study. For now, i was testing out with the example code it it redirects to another app but it doesnt. Am I missing something? other than registering the redirect URI in the integration key page, is there any change i need to make in the demo code for embedded signing to make it work?
As said in support : "There are two primary causes of this error, either an incorrect URI is being passed to DocuSign, or a correct URI has not been registered for the integration key."
I had the same problem, so i realized that appUrl was http://localhost:8080/ds/callback, but should be http:localhost:8080.
So you have to add too a Redirect URI of http://localhost:8080/ds/callback to your Integration Key in your eSignature Admin.
I hope i was clear and sorry for my bad english.
It's possible you're using incorrect environment, use account-d.docusign.com for Demo and account.docusign.com for Production when requesting for authorization code grant.
could this be https vs. http situation?
are you running it on your local at https://localhost:8080/ds/callback or http://localhost:8080/ds/callback? please check. It has to match exactly the same
Another thing to check is the use of trailing slashes in app_url. While my case related to the PHP Quickstart, it's possible this affects the others as well.
My Quickstart application was installed to a subdirectory, at https://example.com/docusign/public/. So the redirect URI was set in the DocuSign dashboard as https://example.com/docusign/public/index.php?page=ds_callback - which is correct but I was still getting the "not registered properly" error.
It turns out that the app_url in /docusign/ds_config.php must not have a trailing slash, so
'app_url' => 'https://example.com/docusign/public', // The url of the application.
works but
'app_url' => 'https://example.com/docusign/public/', // The url of the application.
fails with this error.
You just need to add http://localhost:8080/login like the redirect URI in Docusign and you won't see the error message "The redirect URI is not registered properly with DocuSign" again. It's working for me.
you also need to add a redirect URI for each scenario as in: https://localhost:8080/ds/callback,
https://localhost:8080/ds/callback#/username,
https://localhost:8080/ds/callback#/password
Make sure the protocols are also the same
In ds_config.php there is a comment under app_url saying
// Ie, the user enters app_url in their browser to bring up the app's home page
// Eg http://localhost/code-examples-php/public (no trailing slash) if the app is installed in a
// development directory that is accessible via web server.
// NOTE => You must add a Redirect URI of app_url/index.php?page=ds_callback to your Integration Key.
So try adding this to your Integration Key -> Redirect URI, In my case I'm using port 8080.
http://localhost:8080/public/index.php?page=ds_callback
This works for me.
I would appreciate any hints regarding the following issue:
The problem summary:
While using Negotiate:Kerberos in IIS 7.5, the authorization works correctly right until we setup URL rewriting (using the MS module "URL Rewrite 2.0") - any rewritten URL then returns "401.1 Unathorized" (requests not matching any rewrite rule keep working though).
The setup:
Windows Server 2008 R2 x64
IIS 7.5
URL Rewrite 2.0
Server is in a domain
SPN exists for HOST/hostname and HOST/hostname.domain (created by default)
Pool is using default ApplicationPoolIdentity (no custom account, not network service)
Kernel mode set to OFF
Authentication providers set to "Negotiate:Kerberos" only (no NTLM or annonymous)
URL Rewrite rule as as "^(.*)/$" => "index?x={R1}"
The result:
1) When accessing any URL not matching any URL rewrite pattern, Kerberos is working correctly, i.e. Kerberos ticket is issued (verified using klist), sent (verified using netmon and HTTP headers) and accepted (verified by URL being accessible and appropriate AUTH_USER property set to my domain account name) => no problem here.
2) When accessing any URL matching URL rewrite pattern, e.g. "hostname/foo" the result is:
HTTP Error 401.1 - Unauthorized
You do not have permission to view this directory or page using the credentials that you supplied.
Module WindowsAuthenticationModule
Notification AuthenticateRequest
Error Code 0x80070055
Requested URL http://hostname/index?x=foo
Physical Path D:\wwwroot\
Logon Method Not yet determined
Logon User Not yet determined
(if we try to access the rewritten URL directly, e.g. hostname/index?x=foo, Kerberos works again normally)
The attempts to solve it so far:
After googling, we have tried several options:
turning kernel mode ON: Kerberos stopped working completely, using either default pool identity or network service (I suppose we would need to setup additional HTTP SPN and/or use custom domain account with additional SPN for that account explicitly)
turning "useAppPoolCredentials" ON: no difference
enabling "Failing Request Tracing": surprisingly these failing 401.1 requests ARE NOT generating any output into the fail logs no matter what rule we try to setup (e.g. 400-999) - the folder is just empty (while other errors, like 404 or even handshake 401.x when accessing not-rewritten URLs are generating logs - very strange)
The conclusion:
So far we have reached a dead end - it may be some weird kind of "double hop" issue requiring using a custom domain account rather than default app pool identity, but as we're in fact accessing the same resources, it seems more like a URL Rewrite issue.
Any tips, hints, pointers? Anything would be highly appreciated.
Best regards,
Marek
we face the same issues as you do. By enabling extended error logging, we were able to put the finger on the actual problem, which seems to be a bug in the rewrite module (or at least in some part of IIS, which is related to the module):
When the URL gets rewritten, the access to the new rewritten URL is checked (seemingly hardcoded) using Basic Authentication and NTLM, neither of which has been configured on the Website at hand. The only configured authentication provider is Kerberos. Since the client doesnt send NTLM nor Basic credentials, there is no way this can work.
We (another person on the current project) are sending the issue to Microsoft. I will let you know, when I get any result.
It seems as though you have multiple issues here.
Failed-Request Tracing Logs
To fix your missing logs issue, you must make sure that the user that is running your site's AppllicationPool has read/modify rights to the folder where those logs are generated, otherwise you won't see anything. See the section labeled "Enable Failed-Request Tracing" on this page: Troubleshoot Failed Requests Using Tracing in IIS 7
What isn't clear is the fact that the site's Application Pool Identity (found in Advanced Settings for Application Pool) is the account that needs read/modify rights to that folder.
Once that is fixed you can load the XML logs in IE and see a much clearer picture of what is going on.
401.1 - Unauthorized Issue
A possible fix to your 401 error is to make sure unlisted file name extensions are allowed in Request Filtering. Go to IIS --> Sites --> [your site] --> Request Filtering
You have two options here:
Allow File Name Extension... and add the value "." (minus the quotes), see this answer.
Edit Feature Settings... and enabled the option "Allow unlisted file name extensions"
The 1st option should work well, the 2nd option obviously opens up a gaping hole but allows everything so you should be able to get it working.
I hope that helps.
I'm the IIS admin, not the developer on this site, so the code is opaque to me. I'm stumped, though, for where to look.
Using Windows Forms Authentication, the user is directed to a login page. If their password is expired, they are directed to ChgExpiredPwd.aspx. On our dev and test servers this works. On our production server, the user is redirected to login page again with a "ReturnURL=ChgExpiredPwd.aspx". Not the desired behaviour.
Fiddler says the server is responding with an immediate 302 redirect to the login page. The test server responds with a 200. The IIS properties for the site and for that page have no redirects - all, "The designated file." There's no redirect built into the codebehind so's I can see it. No redirects in the target page, though the redirect is happening server-side, so it has to be in the code somewhere. If I take \bin*.dll from production and put it all on test, it does not reproduce the error.
I'm out of ideas.
Have a look in the web.config file at the root of the site. Forms based authentication is typically configured there and the default behavior is to redirect from a "secure" page to the login to authenticate (if the user has not yet done so), and one of the parameters it passes is the ReturnURL.
This explains it pretty well: http://msdn.microsoft.com/en-us/library/aa480476.aspx