I was able to stand up our GitBlit 1.8.0 server with Federation enabled and it is generating the 3 tokens during startup, however, when logging into the server as Admin, it does not show the Federation link (as per the documentation) in the navigation menu to visit the Federation page for sending a proposal to the mirroring GitBlit server. Google images shows that the link was present in the 1.6.x version but it's not here in the 1.8.0 version. I also looked in the Admin user context menu but there is nothing mentioning Federation.
Where is the link to the Federation page to send a proposal?
I finally figured it out. As per the documentation, the gitblit.properties must include the git.enableGitServlet=true and federation.passphrase=<simplepassword> to enable the Federation feature in the origin server. The origin GitBlit server needs to also contain the following property to display the Federation link on the Admin context menu:
web.showFederationRegistrations=true
Without this property, Federation may be enabled but the link to the Federation page to issue proposals and view the various server configuration settings available for federating will not appear on the main page. The origin server must be restarted for the property changes to take effect.
Related
I am trying to auto login for specific url like webdav url for document.
We want to modify documents uploaded to document library.
We are passing webdav url to ms office to open document. It is our intranet project and we are using ntlm.
I am unable to pass credentials from ms office to our liferay server.
When we click webdav url from our browser where I logged in already then it redirect to office and when office tries to open that document from liferay server then it is asking credentials, as I am already logged in then it should not ask credentials at the time of opening documents using ms office.
I am thinking if we do autologin for webdav url like url="/webdav/*" and able to do autologin then my issue would resolve.
Please help me on this.
I am using liferay 7.2 CE.
Windows
This is a long-standing issue that is not quite related to Liferay. The fact is that when you authenticate in Liferay from the browser it stores a session cookie inside that browser. When you open the webdav url, it's actually ms office that contacts the server and then it doesn't know about your browser cookies. So it does ask authentication on its own.
Now you are using NTLM which is Microsoft own SSO protocol, would it be nice that it does authenticate you on a Microsoft product. It's been a very long time since I had this exact same issue (2014, Liferay 6.1) but I believe NTLM info is only sent in network trusted sites and by default any site is not. You have to make change to your domain controller to allow them.
Next in that time, I think the Liferay NTLM filter was not called on a webdav path, we did have to create a hook to apply it. I don't know if it has been changed since then.
Additional info asked in the comments:
filter hook mapping documentation:
https://portal.liferay.dev/docs/7-1/tutorials/-/knowledge_base/t/servlet-filters#step-2-map-urls-to-your-servlet-filter
The ootb ntlm filter is here: https://github.com/liferay/liferay-portal/blob/7.2.x/modules/apps/portal-security-sso-ntlm/portal-security-sso-ntlm-impl/src/main/java/com/liferay/portal/security/sso/ntlm/internal/servlet/filter/NtlmFilter.java
I was trying to setup OAuth workflow using the sample application as given here
However for some reason, after I enter my okta user Id and password, I never gets the control back on my call-back URL and application just hangs indefinitely.
However the normal Javascript Singn-in widget (check this link) with the minimal authentication does work and I get the control back to the redirect URL. But this is not for an OAuth2 workflow... which is completely useless for me. Because all it does is provide authentication service using Okta tenant app and it will redirect you to your App URL. This does not provide any authorization grant workflow or other OAuth2 complex workflow. May be useful for some application but not for enterprise app where you want to retrieve user profiles, and create a login session based on user profile data retrieved from OKTA.
So my question is why is the OAuth workflow not working using the PHP application that uses JS sign-in-widget? And why there are no instructions or warning on this page for this costly service (this is not free and many org is probably paying for this)?
I spent almost a day trying to setup my Authorization server as per the instruction given on this link, but nothing works. Any idea what must be going wrong ?
Does this entire example works only after contacting OKTA support to enable the Authorization server feature? Because, I also saw a documentation here that says that this is Early Access (EA) feature (and it is probably recently added in OKTA? Extremely frustrating experience).
BTW I sent email to their customer support to enable this Authorization server feature just in case if I am missing something. If this does not work then I will have to create my own OAuth2 server using Laravel 5.4 PHP framework, which is probably the quickest solution and 100% free.
I also tried to test the Authorization server setup as per the instructions provided here.
I was successful in getting the following end point working:
/oauth2/:authorizationServerId/.well-known/openid-configuration
But I am unable to get any scope and claims using api end-point:
/api/v1/authorizationServers/:authorizationServerId/scopes
So in short, I am so far unable to test my Authorization server to get my authorization grant workflow working.
Where can I look for some troubleshooting advice?
Is there another way to check whether I have configured my OKTA Authorization server properly?
I found out that the JS script provided for the PHP sample is not right for the workflow I am working on. So after changing that JS Script, things started to work.
Edit: Also please note that Setting up Authorization server is a new feature (It is Early Access feature) in OKTA. It is not enabled by default. So you need to contact OKTA support team to enable the Authorization service endpoint and functionality provided by it.
Sorry if this is a bit long. Got a requirement to integrate our application with client's main portal site. The portal is maintained with a SAML 2.0 SSO features and as such, we'll need to integrate our login using SAML 2.0 as well.
The integration is done via an iframe, i.e. on the main portal, an iframe with the url pointing to our application. When user is logged in and click on a menu link, he/she will be presented with the iframe page, with our session checking with their IDP to make sure they are valid users. If so, then our application will continue to load as per usual.
The issue is that we'll need to maintain our session on our servers, while they shall maintain the session on their app server. If the user stayed on our site for a while, the session on the client main portal will timeout. And when the user click on the main portal link, they will be required to log in again.
It is suggested that when the user tries to navigate to the main portal pages, it will call a service (for now assuming it's an IDP) on our end to check whether the user session is valid or not. If it is, then we need to return a SAML response to them to validate the user.
We're exploring setting up an IDP service at our end to facilitates this, but it seems to be overkill to me. Is there a way for an IDP to only provides check on a user's session? Or is there a better option for us to achieve this?
Things that could not be changed:
1. SSO language: SAML 2.0
2. Server: Weblogic 10+
3. HTTPS a must.
Appreciate any suggestion or feedback.
Thanks.
Based on the provided information, I assume your application runs on WebLogic 10+. If the remote server too uses WebLogic you might be able to just implement the SAML authentication between the WebLogic federation. This will simplify everything and you don't need to do complicated application customization.
If the remote site does implement SAML and not on WebLogic, you still should be able to implement SAML authentication through the WebLogic configuration. This is straightforward and can be done without much hassle.
However, please be reminded that WebLogic 10+ does not support SAML SSO logout. Therefore, this needs to be handled separately.
Our application server recently met a really weird problem. We deploy same version of build into different app context for our different client, say /clientA, /clientB
Today one user in clientA portal reported that he suddenly saw clientB portal information. We checked the client A portal log, and the log shows that at, for example, 16:01:10 the user clicked a link, and then at the same time point, clientB portal log shows that the session does not have the required 'member' value. (for every link our application checks if user current session contains required 'member' value, if no we direct users to our front page), then in portal A log it shows our system tried to direct user to front page, however, instead of showing front page content JBoss sent ClientB portal information back (which can be seen from the screen shot our client sent to us).
We are using Apache 2.2.22, Mod_jk 1.2.20, JBoss 4.23, and currently there is no cluster used. The mod_jk file configuration is:
worker.list=admin
worker.admin.type=ajp13
worker.admin.host=localhost
worker.admin.port=8009
worker.admin.connection_pool_size=240
worker.admin.connection_pool_timeout=120
worker.admin.socket_keepalive=1
worker.admin.socket_timeout=120
#worker.admin.recycle_timeout=300
Can somebody explain why it happens???
We have three servers that all share the same database. One server is internet facing.
I have a web page in an IFRAME in CRM that talks to the CRM web service using the standard method of connecting for on-premise. When this IFRAME is displayed through the IFD with users logged in through the forms authentication element, you are asked for login credentials.
How do I get around this?
EDIT
The IFRAME that targets the CRM service is on four servers. Two of the servers are used for IFD and On-premise use. The other two are for on-premise only. They are all in the same domain. All of the users are internal users that can log in through the web if they are using a customer's computer or a machine in an Internet cafe and therefore can't use the VPN.
A few questions to better understand you issue. Is the iframe which targets CrmService on the same IFD server? Is the IFD server on the same domain as the rest of the servers? When you say users are logged in are you refereeing to local domain users or external users?
I suspect the problem is not the services, but the IFrame. When you authenticate to MSCRM via on-premise you are doing Windows Authentication, and when you should the IFrame that authentication request is done again. Since the browser knows everything it needs this is all handled transparently.
When using IFD, you are not using authentication on the web server level - you are doing it using forms based which is on the application level. You IFrame though is still wanting authentication, and thus the iframe prompts for authentication.
If you were having a service problem, the IFrame would display and what ever action triggers the service call would fail with a 400 or 500 error.
So the question comes in how do you build a web page that can cater for windows authentication and forms based? Well that is easy in MSCRM, first make sure you are not running authentication on the web page - set it to anonymous. That ensures no more popups, then make sure you use the CrmAuthenticationToken code to get the token and use that for all calls. You should not be setting the .Credentials property of the service itself.
Assuming you're deploying your page within the CRM website (and not its own virtual directory) then here is pointing you at the SDK article for what Robert mentioned:
See the SDK topic titled: Authentication from an ASPX Page.
In my experience you should always use the CRMImpersonator in your web pages within the CRM website.
Now if you've got your own page running on its own website:
You'll want to see the Discovery service and obtaining a CRM Ticket for accessing the services.