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
Related
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.
I need a good advise and wanted to know whether a solution is feasible or not. Right now one of my customer has a common login application which is based on Forms authentication(ASP.NET) using membership provider. All internal users use their AD credentials to logon and external users use custom username and password. Both are wrapped via Forms authentication. Now the new proposal is to replace this Forms authentication with ADFS. I have gone through various articles over internet and not able to come to a conclusion. Let me list my findings so far with ADFS extension points.
1) It is possible to add a custom attribute to ADFS claims by the approach mentioned in https://blogs.technet.microsoft.com/cloudpfe/2013/12/27/how-to-create-a-custom-attribute-store-for-active-directory-federation-services-3-0/.
2) It is possible to add a second level of authentication( or multifactor authentication) via the approach https://blogs.msdn.microsoft.com/jenfieldmsft/2014/03/24/build-your-own-external-authentication-provider-for-ad-fs-in-windows-server-2012-r2-walk-through-part-1/. Here I understand that after first level authentication done by AD then only our external provider will come into picture.
So I have a general question that is it really possible to achieve what I am looking for with ADFS. Please let me know.
This is based on where the user accounts are stored. If both internal and external users are in AD, you can just redirect to ADFS.
If internal is in AD and external is in an untrusted or other LDAP source, using ADFS 2016 you can link to both these account stores and still offload authentication to ADFS.
If external is in SQL, you can either use a virtual directory in front to project it as an LDAP store (previous option) or use IdentityServer.
If externs is something else, you'd need IdentityServer.
Thanks //Sam (#MrADFS)
Yes - you can add a custom attribute store.
Yes - you can add a custom authenticator.
A better way might be to use thinktecture's IdentityServer 3.0 for the ASP.NET Identity part and then federate IdentityServer and ADFS.
I often have a need to secure a single page (i.e. Reports) on a public facing app so that only authorized users may access the page. In the past, this mean setting up a custom login form or using the ASP.NET membership provider or something else far too complex to serve the purpose. Is there an easier (safe) way to secure a single page in this fashion?
Some things I've considered:
Client certificates (initial setup is a pain)
A single master password (works in a pinch, but feels dirty)
Restrict access by host address (cumbersome when the need arises to allow external users access to the page). Also, need to support access via proxy (X-Forwarded-For) which can be faked by technical users)
Are there other options? Recommendations?
You can do it in your web.config file something like what is suggested here. As far as authentication is concerned the easiest way is to use windows authentication.
A login system is your best option. If you don't want to go through the trouble of setting up and managing a login system yourself, consider using OpenAuth.
You can achieve functionality pretty easily using DotNetOpenAuth. Users can then log in with their Google, Yahoo, StackOverflow, etc. accounts, and you get a token that you can store to limit access with.
I need to implement application that supports LDAP authentication.
I want to know in detail how such network works. Can you recomend some reading about it, a book perhaps with broader explanation of LDAP authenticated networking or at least some online tutorials. I would like to see step by step guide of creating such network and if possible, cross platform theory with samples in Win and *nx systems.
Thanks.
LDAP System Administration is the book I read when I first started with LDAP.
That and the OpenLDAP Administrators Guide.
In addition to gacrux, I'd suggest looking at
Lightweight Directory Access Protocol (Wikipedia) for an introdcution
LDAP Linux HOWTO by Luiz Ernesto Pinheiro Malère
Understanding LDAP (part 1) and Understanding LDAP (part 2) on devshed.com
LDAP and OpenLDAP (on the Linux Platform) slides
Are you looking to build new LDAP server infrastructure, or are you looking to use an existing service?
If you're building infrastructure, then Understanding and Deploying Directory Services has long been the book to get. It clearly explains what LDAP is, how to design your schema and directory information tree layout, and how to choose an appropriate directory topology.
If you're trying to authenticate users against an existing LDAP service, you would be best served by reading the library docs for your language. The typical process for authenticating users goes like this:
Take the user's user id and search against LDAP for that user to obtain the disinguished name (or DN, a unique name for each entry in the LDAP tree).
Use the retrieved DN and the password the user provided to "bind", or authenticate against the LDAP server as that user.
Check the return code from the server to determine whether the bind was successful.
Based on the results of the previous step, allow or disallow the user.
I must be stupid, because all the articles I've seen on OpenID in ASP.NET have simply confused me on the issue. I'm pretty sure I understand the concepts involved here, I'm just a little fuzzy on how things look on the back end side of things.
So a new user comes to my website and wants to create an account. Here comes the flood of questions:
Is the first step here to have him pick which openID provider he will use to sign in?
Do I prompt him for a user name on my system?
Do I need to tie him to the same openID provider each time he returns, or can he select a new provider each time?
What does the database look like here? Do I have his username in a table and that is linked to an openID provider?
What if the user doesn't have an OpenID account? Should I allow him to create a traditional account on my end, then expose myself as an OpenID provider?
What am I missing here? I'm usually pretty bright, but this area has been like kryptonite to Superman for my developer smarts. Thanks in advance!
Adam
This page is a step-by-step tutorial on implementing OpenId on a web site. I believe it will answer all your questions about the mechanics of adding it.
A Recipe for OpenID-Enabling Your Site
If the user doesn't have an OpenId I would just allow them to register 'normally', storing their credentials for local use. There is no need to add the extra complexity of becoming an OpenID provider unless you have a business case for that.
Dude, you're not alone. OpenID confuses everyone except the people who designed it, and even then, I'm not so sure it doesn't confuse them either since there are multiple OpenID providers and slight incompatibilities between them, depending on whose libraries you use.
Imagine the user is a sql "table" himself (that table contains his "credentials"), and you have a table of profile data specific to your website that you own. The OpenID url is a "foreign key" that you use to "join" these two tables. You must prove to yourself that he really owns that OpenID url before accepting it (or associating it with your private profile data). You're essentially "offshoring" the authentication portion of your site.
So ultimately, you use an openid client library that does the work for you on your website. They register as normal filling in "full name, "age," etc (whatever you want) but they provide an openid url instead of username/password. The library looks after verifying they really own it. You have to trust this library to do that. You then store all of your profile data with that openid. Done.
While you could offer your own openid provider, it's not worth it at this point. There are plenty out there already. What you could do though, is offer a traditional username/password INSTEAD of openid. The idea of openid is that your register ONCE with a provider, and then just prove you own that URL to any site that wants to use it to identify you (instead of username/password).
Make sense?
-Oisin