I have set up a SimpleSAMLPHP IdP, making use of LDAP as my primary auth source, which is successfully being used by about 8 SPs. I need to add another SP, but this one needs to use a different auth source. Any suggestions on how to do this? Specifically, the auth source I need is to the same LDAP server, but users for this new SP need to have membership in a different LDAP group. I have set up an additional entry in the authsource.php file, but I can't figure out how to point the single SP at that new auth source.
Any suggestions? I'd like to avoid having to set up a separate IdP, if at all possible.
Related
My goal
overall goal
I want to serve various applications running on docker containers hosted on the same server, each on a subdomain of company.com. And I want only people from my organization (Microsoft AD azure) to access subdomains, in some cases even only people having specific AD groups.
goal specific to Keycloak
I simply want to have specific realm roles have access to specific subdomains, and nothing else. And this, using only a single realm client (see further for explanation).
what I have achieved to do
I have linked several applications on a server and serving each using traefik on a specific subdomain. For example app1.company.com and app2.company.com.
I have also made a middleware so that all routers using it will make sure users must login. I have used a thomseddon/traefik-forward-auth container that I called oauth. I am using Keycloak and I have successfully linked an Azure Active Directory as identity provider. For this, I enabled a single-tenant application and used its client id & key. I also mapped successfully some AD group to a Keycloak role.
Within oauth configuration, I have added the client id & secret from a single keycloak client rather than from the azure application. I believe this is mandatory if we want to use traefik to redirect trafic.
Now, only people from within my organization can access each app. Success!
Some documentations I used
Homelab Single Sign-On & TLS
How to Configure Microsoft Azure Active Directory as Keycloak Identity Provider to Enable Single Sign-On
what I want to do
Each application has its own subdomain. However I cannot figure out where to make it so that some subdomains are accessible only if a user has a specific realm role (linked automatically depending on a AD group thanks to the above-mentioned mapper).
I thought of adding resources within the Keycloak client, but I don't find how to do it using subdomains.
other alternative is to make one client per subdomain, but this means I need to run one oauth container per subdomain... This seems overkill & a waste of resources without counting maintenance.
The only relatively simple solution I found was to create one Keycloak client per type of permission rules (aka Roles in Keycloak) I wanted.
Then for each type, I had to make a traefik-forward-auth container and connect it to each Keycloak client. I am still using the same Identity provider, so once you've configured it to generate roles, you only need to tell which roles may use which client.
To give an example, you want to have 3 types of permission rules: one for admin, one for trusted users, and one for untrusted user. It could look like this:
admin.example.com
trustedusers.example.com/app1 and trustedusers.example.com/app2
untrustedusers.example.com/app3 and untrustedusers.example.com/app4
You would then have 3 forwardAuth middlewares within traefik.
It is a little bit more cumbersome, but your applications are still connected to your OIDC provider using a single key, then you manage the details using keycloak and these clients.
Of course there is still the solution to have one client per application as is originally planned. This may be unnecessary, and cumbursome if you have a large number of applications (one additional container per application + additional middleware).
Scenario:
I have an OpenAM instance with only the default realm configured. I have set up my Organization Auth Chain with a single LDAP module that allows my users to self register.
I also have set up another chain, called adminChain and set as the Administrator Auth Chain, with a single Data Store module in order to allow the amAdmin user to login using the /console url.
Problem:
My problem is that this second chain allows also non-admin users from the LDAP data store to login, which actually makes sense because it's using the DataStore module. But then how can I prevent normal users logging in with the admin chain? I want them to be limited to a specific chain only.
You should use the root realm for administration and sub-realm for operations.
In fact OpenAM will use all configured user data stores in a realm when it's configured to support the requested operation.
As a workaround you could set the value of Authentication Naming Attribute in the user data store config to an attribute which does not exist in the entries. This will make 'datastore' authentication for regular users fail. AmAdmin can still authenticate because this identity is stored in a special data store which does not show up in OpenAM configuration.
Be aware that you may be subject of a bug, as in older versions the DN-Cache is leveraged during authentication.
I currently have a MVC4 home-grown secure token service (STS) that communicates with our own authentication database. All is working just fine with this setup. As a new feature I need to add the ability for single sign on (SSO) through ADFS2 for those users that are on the domain (bypasses the current un/pw screen, and they're just 'in'). To be clear there really are 3 different login possibilities that need to be handled: domain user (SSO), domain credentials (domain user not on domain entering their domain un/pw), and the original un/pw auth from database. Knowing what I know about adding web.config settings to the relying application to wire up the STS, how would I wire up both wsFederation passive redirect options (current redirect to STS for un/pw, and the ADFS option)? Is this something that would have to be handled in code, through an overloaded class such as WSFederationAuthenticationModule? What would be the best way to handle what I want? Any code examples? Thanks for your time!
You just have your login screen on your custom STS and two additional buttons, "login with ADFS" or "login as domain user". Both buttons are redirects to two other STSes your STS is federated with (your STS plays then role of either an Identity Providing STS or a Relying STS).
That is not very complicated. What you need is to create two SignInRequestMessages and using their WriteQueryString build two urls to two different STSes. Another way would be to use the WSFederationAuthenticationModule::CreateSignInRequest method.
http://msdn.microsoft.com/en-us/library/system.identitymodel.services.signinrequestmessage(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/system.identitymodel.services.wsfederationauthenticationmodule.createsigninrequest(v=vs.110).aspx
Consuming responses is tricker as you need a single uri (or two different uris) that play an endpoint roles. In the uri you need a token receiver and try to create a token out of the SAML sent by the provider.
If you peek at the source of a community replacement of the wif:FederatedPassiveSignIn method I wrote once, you will get the idea
http://code.google.com/p/net45federatedpassivesignin/source/browse/trunk/+net45federatedpassivesignin+--username+wzychla#gmail.com/Community.IdentityModel.Web/Controls/CommunityFederatedPassiveSignIn.cs?spec=svn6&r=6
(at least half of the code is responsible for the WebForms user control infrastructure but the other half is what you are looking for)
Unfortunately also, such custom mixed scenario is not easily handled with just the configuration of federation modules.
I have successfully assembled over a half dozen passport strategies (facebook, twitter, linkedin, instagram, tumblr, google, youtube) exchange account info with oauth1 and oauth2 token, into a single standalone auth server that saves session in Mongo and creates active profiles, with token/session/code/id fields and with many standardized atribute fields in SQL server using Tedious.js. These passport tools are excellent, thank you.
My last challenge for this project is not going as well, username and password into an active directory repository, to look up and auth in the same way. I have been trying over and over again passport-ldap, passport-ldapauth (based on ldapauth-gfork, based on ldapjs), passport-windowsauth and passport-kerberos, and seem to be getting related credential errors (deep in code, adding console.logs to try and figure out what I am getting syntactically wrong).
Are there any other resources and documentation to accessing LDAP/AD in Node.js using any strategy of Passport? The DN versus ou syntax and where the account access user (have a service account specifically set up to access the AD) for the repository versus the account user you are looking up and the filters make it very difficult to find anything error related to figure out where I am going wrong. Do you match to sAMAccountName or uid? I keep consistently getting "unauthorized" errors.
Unlike the other 70 passport strategies, where the doc and examples are clear and just work, not so much for ad/ldap passport. Can anyone point me to a good test, doc or setup that works well specifically with Passport.js and Active Directory?
While this is an old question I thought, as the maintainer of passport-ldapauth, I should clarify LDAP authentication a little.
LDAP authentication is different from those strategies you've used before. Those OAuth strategies can really be configured only one way - provide the required options, and then it works. This part is the same with LDAP, but the actual values to the options differ from one server to the other. The questions you are asking, like do you match to sAMAccountName or uid, are really up to you and the LDAP server.
General things like what does a DN look like, what is search base, or what is the syntax of search filter have been defined extensively in RFCs. If one is not familiar with the basics it can be difficult to get the authentication to work. Often the AD/LDAP server maintainer input is needed to have proper settings, eg. what search base allows finding all required users but does not cause unnecessary load on the LDAP server.
LDAP authentication usually works in three steps:
Using a service account (in passport-ldapauth, bindDn and bindCredentials), bind against the LDAP server.
Once bound, perform the configured search substituting the placeholder with user provided username. This determines if the given username is found from the LDAP server.
Use the DN of the search result, together with user provided password, and bind against the LDAP server. This verifies the password.
If you wish to have users login using their SAMAccountName, your search filter could be eg. (sAMAccountName={{username}}). If you wish that the users use uid, the filter could be just (uid={{username}}). If you want to enable both, use (|(sAMAccountName={{username}})(uid={{username}})). The search filter syntax is specified in RFC 4515.
I was able to authenticate to AD via passport-ldapauth.
One key was knowing to use server opts which are different than in some LDAP examples online
searchBase: 'ou=Accounts,dc=mydomain,dc=com'
searchFilter: '(sAMAccountName={{username}})' // {{username}} comes from the html form.
You also need to know if you need ldaps and TLS or not. (I did not) I spent a good amount of time digging through ldapjs.org.
Microsoft have released an official library for this:
https://github.com/AzureAD/passport-azure-ad
Add to your project from npm directly:
npm install passport-azure-ad
Or Auth0's passport-azure-ad-oauth2 for OAuth2 flows.
I am not sure how flexible you are with your requirements, but I was researching the same subject and stumbled upon a specific solution from Microsoft that uses AD FS as an Oauth provider
https://msdn.microsoft.com/en-us/library/dn633593.aspx
A superficial reading shows that a web client contacts AD to get a JWT token, then this token is sent to your server, which then authenticates the token with the AD server.
The AD server needs to be configured to accept your server as a relying party that needs its identity service.
I am a consultant. The company that I am doing work for has given me limited access to a couple servers. I do not have permission to log on to the ldap server.
I am using the following to bind:
(sAMAccountName={{username}})
If I cannot physically log on to the ldap server am I not able to authenticate via ldap?
If they give me access to log on to the server, ldapauth works.
Gina
We have one web application (sharepoint) that collects information from disparate sources. We would like to be able to link users to the main websites of those various sources and have them pre-authenticated. I.E. they enter their credentials for the other sources (which are a number of different types LDAP, AD and home grown!) and we retrieve some information for them, and remember there details (Possibly Single Sign-on to keep em nice and safe). The user can then click a link that will open the full app in another window already authenticated.
Is this even likely to be possible?
Office Server has a Single-Sign-On api as a builtin feature. you may want to look into that. It enables you to register user credentials securely, and to access it at runtime.
You need to act as a web browser acts to different sites with storing credentials (usually in cookies) locally. Use therefore a a proper client library with cookie support. This could go probably for most of sites. There are sites using HTTP authentication, which are also easier to access from appropriate client libraries. The most demanding can be access to SSL websites, but again, most client HTTP libraries cover that nowadays as well.
All you need now is just to prepare your web application to act as a proxy to all those separate web resources. How exactly this is done in Sharepoint, well, I hope others will answer that...
True Single Sign-on is a big task. Wikipedia describes common methods and links to a few SSO projects.
If you want something lighter, I've used this approach in the past:
Create a table to store temporary security tokens somewhere that all apps can access.
From the source app (Sharepoint in your case), on request of an external app, save a security token (maybe a guid, tight expiration, and userid) in the token table.
Redirect to a request broker page/handler in the destination app. Include the final page requested and the guid in the request.
In the broker, look up the security token. If it exists and hasn't expired, authenticate, authorize, and redirect to the final page if everything is good. If not, send a permissions err.
Security-wise, a guid should be near impossible to guess. You can shrink risk by letting the tokens expire very quickly - it shouldn't take more than a few seconds to call the broker.
If the destination app uses Windows Auth and doesn't have role-based logic, you shouldn't have to do much. Just redirect and let your File/UrlAuthorization handle it. You can handle role-based permissions with the security token db if required.