I've trying to find the answer but after reading a bunch of documentation I think it's not possible, but I would be a nice feature. The problem is I want anyone to access the cached repositories but I don't want them to access the web user interface.
The only way I have figured out is tweaking the nginx configuration to allow access only to certain endpoints like raw repository view. Anyway it has some problems which I've not totally resolved.
You could set up a SAML SSO redirect that forces a user to login, and if they fail they are not redirected back to the Artifactory instance. That's the only way I know of that won't let users even look at the front page of Artifactory.
They would get caught on step 3 after an automatic redirect: SAML SSO Login Process
The obvious downside with this is that you need to have a SAML SSO setup in the first place.
Related
I've got some external users in another system that may/may not be using OWIN. (I've actually got this problem in a couple projects) I'm trying to solve this with IdentityServer4 and it's Authorize Endpoint but want to make sure I'm on the right path.
Our goal is to have users click a link in the external app and be redirected to IdentityServer4. I would like IdentityServer4 to authorize users coming in from this endpoint, add a particular role or claim, and allow them into the clients without presenting a login screen. Is this possible? I'm having trouble finding examples.
Identity Server 4 Authorization Code Flow example
This is the closest I could find, but we're looking for a framework agnostic solution that doesn't involve modifying the external apps, as I don't have access to their source code in all instances.
I'm looking for a flow like this: User goes to https://someexternalapp.com, clicks a published link like https://identityserver.myapp.com/authorize?requestSecret=asdf1234&username=bob and is redirected to https://identityserver.myapp.com/external?token=dasdfasdf where the claims are issued, and finally redirected to https://someclient.myapp.com with authorization.
Am I on the right track? I'd hate to waste much more time on this and end up at a dead end, could anybody point me in the right direction?
Have a look at Sign-in with External Identity Providers
This will allow you to create a cookie in the https://someexternalapp.com/ app which is then used by identity server to do the authentication without user interaction.
Good afternoon,
Here I am working on Symfony 4 and on the Symfony Security module.
I need to customize the authentication of my users without using plugins such as Fosuser.
This is for the following reasons:
The user connects to a "main" server (ldap) with his login/password
I need to be able to retrieve his credentials to test his account on other ldap servers in parallel.
When the user is authenticated on the main one, the user is redirected to a page telling him if everything is ok or not on the other servers. In case it is not, he has the possibility to update his account.
But the documentation deals with "simple" cases and here I am a little lost.
I tested several possibilities (authentication with Guard, test of creation of a personalized provider...) without results.
I would need to understand the mechanisms of symfony authentication to create a custom authentication.
If anyone has a lead to guide me, that would be great.
Thank you in advance.
I think you need to divide your action into 2 stages:
Authenticate by LDAP against first server, i.e. with Symfony LDAP Component - this can be done by standard authentication form and FOSUserBundle
When you are already authenticated interact with second server in controller action. This can be done by writing entire code in Controler or in service designed to interact with this LDAP server. You can even use the same Symfony LDAP Component as before, but you will need to configure another instance of service by hand.
I have authenticated using Siteminder & I have obtained accessToken.
Now there is another application that comes under the scope of same application.
I want to use Alfresco there without any need of further sign-up. Basically I want to implement single sign on.
I don't know Siteminder, but sso is possible in alfresco.
You'll have to look at how the authentication subsystem work. You'll find the configuration under alfresco.war\WEB-INF\classes\alfresco\subsystems\Authentication\ you can redefine them under /shared/classes/alfresco/extension/subsystems/Authentication/
Things exist for:
alfrescoNtlm (alfresco's own mechanism)
kerberos
ldap
ldap-ad
passtrhu
external <- this on is a good candidate for you
With external you can tell aflresco to trust what comes from an url. You'll find information here http://docs.alfresco.com/5.0/concepts/auth-external-intro.html or there http://smasue.github.io/alfresco-external-sso
I hope this helps
Given is an application behind a Nginx configured as reverse proxy. The application requires user login via a web form and HTTP POST. Is there a possibility to provide the credentials of a generic technical user to Nginx and let it automatically do a login, so that users don't have to login explicitly anymore?
It might be tough without some kind of module :) but If it is an internal application you might tell nginx to to add certain headers to every request and authenticate by them. But if it is a production app I wouldn't go this path :)
I'd like to be able to use these "best of breed" opensource solutions, with the only requirement of some sort of single-sign-on between the different sites. I don't want my users having to log-in in 3 different places, so I though it could be possible with OpenId.
Has anyone tried something similar?
OpenID will not avoid the problem of having to sign in 3 separate times. It was allow the user to share the same login credentials between the sites, but they will have to actually log in to each of the three systems. If that is not a problem, go with OpenID. If it is, you have two options:
Use an LDAP server to authenticate on all three sites. I think all three software packages have modules/plugins for LDAP (Drupal, Moodle, MediaWiki). Once you have the LDAP server running, the rest should be easy.
Write custom modules/plugins for each platform that authenticate against a single database. Maybe you could use the Drupal database as the primary one, and have MediaWiki and Moodle authenticate with that. So, effectively, the user will only have an account on the Drupal site, but will get access to all three. This is basically the same idea as an LDAP server, but might save you some overhead and complication.
There is also the Moodle Integration module for Drupal that attempts to accomplish the same thing, only without MediaWiki in the mix. I would check that out.
Good luck!
here are three possible solutions: (1) sigle sign-in site, (2) inject login/register forms into all sites using server site includes - SSI and (3) - ajax.
Single sign-in site.
suppose you have site1.domain.com and site2.domain.com and you want to login/register at both simultaneously. Probably the easiest way to do it will be to create another domain e.g. login.domain.com that will do the job. Your login/register application will need access to databases for site1 and site2 and/or their api's. Since login status usually resides in the cookies, your login application will need to set those login cookies to both sites simultaneously (on successful login/registration) and delete on logout.
To set cookies for all sites from login.domain.com - all of the must sit on .domain.com and cookie domain parameter must be .domain.com
If your solution needs both api access (to the other applications) and access to the same database by several applications - you may need to deal with database transactions. This is because new registrations won't be visible on other sites until transaction is committed - so for example - you can not call api from within login code to retrieve cookies before committing the transaction with the new registration.
One important detail. If you already have users separately registered at site1 and/or site2 but not on both your signon site will either have to handle those cases or you'll need to sync registrations manually yourself upon deployment of your new registration system. Manual fix won't be possible when extra user input is required to complete the cross-site registration. This point also becomes important when you add new sites requiring some new user input for the registration.
Finally, carefully choose domain name handling OpenID. To the best of my knowledge it is impossible to transfer openid endorsements across subdomains without users consent - please correct me if I am wrong. You don't want to ask users to re-register just because you decide to rename the sub-domain.
server side include (ssi) method
Another solution is to inject those forms via sever-side includes into all sites. This may be considerably harder and will depend on the type of webserver in use and will work slower.
A pre-requisite here is that all your applications run on the same subdomain - so that openid works for all of them.
I've once built common user registration for MW (php) and cnprog (python/django).
My solution was to display the same exact registration form on the wiki and the forum site, while generating and processing this form with django. I did it this way because wiki and forum "skins" are so different that I did not want to surprise visitors with the dramatic change of site appearance when they go to the registration page. This is complicated and I will not do it again :) and instead would go with single sign-in method.
in order to display django output through mediawiki I've created a wiki extension printing apache "include virtual" call to glue django-generated content with the wiki output. This comes with problems.
Apache include virtual on my installation cannot POST to subrequests and cannot pass cookies from subrequests and cannot pass redirect responses (all http headers will be thrown out) to the upstream user requests.
So I've added "was_posted=true" to mark the posts for django and a secret code to prevent cross-site forgery. To get the cookies out - had them printed with cookie_morsel.output_js() in python. So javascript must run on the client for this to work. Any redirects will have to be done with javascript too. Extra work will still be needed to upload files (like avatar picture).
So single sign-on may be the best solution.
ajax may be a neat way around - just build forms in all of your sites with javascript and submit them via ajax. Will work fast and will not break appearance of your various sites,
but this won't please the folks allergic to javascript.
Actually, the only method that does not require any javascript is single sign-in site.
Posted this because I've spent enough time building this thing for MW and django - an hour of typing did not make a difference :).