I am pretty new to Authorization/Authentication with openid connect. I guess I lack some basic understanding on how to set up a proper backend infrastructure.
There's a keycloak server running through which I want to authorize/authenticate my customers.
The user logs in by his company credentials and then should be authorized/authenticated against our backend service, which provides a REST-API.
So our part is to implement the backend service and use openid connect as authorization/authentication.
Could you tell me what components/software needs to be implemented on our side?
Often the Authorization Server is an external cloud system that your UIs and APIs just point to, with URLs equivalent to this:
https://api.mycompany.com/myapi
https://web.mycompany.app/myapp
https://login.mycompany.com
Not sure if this quite matches your setup but typically you provide some or all of these domains:
API
Web Hosting
Authorization Server (Keycloak)
My personal preference is to use Local Developer PC Domains to match the above. If it helps you might just be able to repoint my Open Id Connect
Code Sample to your infra once configured, in order to verify that it works.
Related
We are developing asp.net core applications that will require sending emails with gmail among other providers (client accounts). This applications will not be hosted by us but by many of our clients.
The application may be hosted on their domain or no domain at all (IP address only).
I am struggling with which authorization process I should use since I can not use the Javascript client or any redirect URI method due to unknown origin/domain. I also can not use localhost origin since there is no way for me to start a local http server from a browser. Programmatic extraction is deprecated. The only thing I am left with is manual copy/paste but apart from it being very user unfriendly Google documentation states that that might be deprecated in the future as well.
Am I missing something?
Please point me in the right direction as to how I should proceed.
I need to find out what's the best way of securing a WCF web service I'm writing. The service will be hosted internally and will perform checks against Active Directory and a third party database.
The service will be called by a public-facing webpage on a different server (a sign up page) and nothing else will be able to access it (due to firewall rules). The web page will NOT require credentials to access it.
The service will take a username and another field and check to see if they're an existing AD user. If they are, it will check to see if they have a personal (non-work) email address in the third-party database. If not, it will ask them to specify one.
Website <-> Service <-> AD/Database.
If these firewall rules are in place, do I need to go about securing the service?
These codeplex application scenarios might help you configure what you're trying to achieve:
Internet – Web to Remote WCF Using Transport Security (Trusted Subsystem)
Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
This guide is well put together defiantly something to look into it covers all situations including yours.
http://wcfsecurityguide.codeplex.com/releases/view/15892
After some theoretical help on the best approach for allowing a SaaS product to authenticate users against a tenant's internal Active Directory (or other LDAP) server.
The application is hosted, but a requirement exists that tenants can delegate authentication to their existing user management provider such as AD or OpenLDAP etc. Tools such as Microsoft Online's hosted exchange support corporate AD sync.
Assuming the client doesn't want to forward port 389 to their domain controller, what is the best approach for this?
After doing some research and talking to a few system admins who would be managing this, we've settled on an two options, which should satisfy most people. I'll describe them here for those who were also interested in the outcome.
Authentication Service installed in the origanisation's DMZ
If users wish to utilise authentication with an on-premises active directory server they will be required to install an agent in their DMZ and open port 443 to it. Our service will be configured to hit this service to perform authentication.
This service will sit in the DMZ and receive authentication requests from the SaaS application. The service will attempt to bind to active directory with these credentials and return a status to indicate success or failure.
In this instance the application's forms based authentication will not change, and the user will not be aware of the authentication behind the scenes.
OpenId
Similar to the first approach, a service will be installed in the client's DMZ, and port 443 will be opened. This will be an OpenId provider.
The SaaS application will be an OpenId consumer (already is for Facebook, Twitter, Google etc login).
When a user wishes to log in, the OpenId provider will be presented, asking them to enter their user name and password. This login screen would be served from the client's DMZ. The user would never enter their username or password into the SaaS application.
In this instance, the existing forms based authentication is replaced with the OpenId authentication from the service in the client's DNZ.
A third option that we're investigating is Active Directory Federated Services, but this is proprietary to Active Directory. The other two solutions support any LDAP based authentication across the internet.
Perhaps this might help…
This vendor, Stormpath, offers a service providing: user authentication, user account management, with hookups to your customers’ on-premise directories.
What about an LDAPS connection to the customer's user directory? They can firewall this off so that only your servers have access if they're concerned about it being public. Since it's SSL it's secure end to end. All you need from them is the certificate from their issuing CA (if it's not a public one). I struggled to get this working for an internal web project in the DMZ and there's a real lack of any guides online. So I wrote one up when I'd got it working:
http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/
Your best bet is to implement a SAML authentication for your SaaS application, and then sign up with identity providers like Okta or OneLogin. Once that's done then you can also connect it with ADFS to provide Single Sign On for your web application through Active Directory.
I'm just doing this research myself and this is what I've came across of, will have more updates once implementation is done. Hope this gives you enough keywords to do another google search
My understanding is that there are three possible solutions:
Installing something on the domain controller to capture all user changes (additions, deletions, password changes) and send updates to the remote server. Unfortunately there's no way for the website to know the initial user passwords - only new ones once they are changed.
Provide access for the web server to connect to your domain controller via LDAP/WIF/ADFS. This would probably mean opening incoming ports in the company's firewall to allow a specific IP.
Otherwise, bypass usernames/passwords and use email-based authentication instead. Users would just have to authenticate via email once every 3-6 months for each device.
I have to begin implementing this for an upcoming project and I'm seriously leaning towards option #3 for simplicity.
I am working on a security component to use with an ESB for a client with very concrete high level requirements:
Integrate into an existing IWay service manager version 5.5 ESB (there is no security system in the existing set up).
Provide authentication and authorisation level information from source data stored in an existing active directory server used for another system (preferably using LDAP).
Authentication and authorisation should be performed in the ESB as the interface for the ESB will be exposed to both internal and external clients so total control over the client is not possible.
The client can not be relied up to have a certificate to allow bilateral SSL authentication, however unilateral authentication, where the client checks to see he is hitting the correct server is possible, so HTTPS connections can be established.
The service should sit on Weblogic (but I will be happy to take suggestions regardless)
Further information:
IWay ESB is a commercial, closed and fairly poor solution, in version 5.5 it provides no out of the box solution which fits the requirements. it is also stateless so no sessions can be maintained other than using a cookie or some method similar to store information.
Current ideas:
To implement a SSO service that is added to the messaging bus which provides a identity provider, service provider functionality, so an initial authentication will provide a token, which can then be stored by the client and passed with each subsequent request to be authenticated and an authorisation level passed (which i believe to be a fairly standard design pattern).
Research has been carried out on SSO + SAML implementation, openAM, Shibboleth, CAS all seem to provide a too complete solution which caters more for a portal type architecture (like CAS) or from a system where the initial SAML identity token is received from another sever altogether and then brought to the system (like googles implementation of SAML for some of its services).
I have also looked into JBossESB, openESB and service mix solutions which seem to use a bespoke implementation of SAML which can't be ported onto Weblogic and Zxid which has limited documentation.
It is a complex undertaking so I am expecting more high level architectural styles and library/project suggestions rather than complete solutions. I am under the impression that this should be a reasonably common requirement, a authentication and authorisation service for a ESB which uses a token system to prevent credentials having to be continually entered or stored in plain text but I am unable to find much information, what am I missing?
Any further questions I would be more than happy to elaborate.
It seems a solution using SAML is a valid solution for when users potentially/do require to access a third party service on an ESB but don't want the third party service to be aware of the security specifics of the ESB and the credentials information of the user. This way the ESB may provide a SAML token provider where the user can get the ticket and transport it to different services for authentication, the services then check back with the token for authentication and possible authorisation information (with SAML2 only). In addition to this SAML could be used like open ID where users are managed externally and users go to the external token provider to get SAML tickets.
This was a valid solution for us as the the client wanted to be very aware of the users accessing the ESB and there was to be no plan to access third party services as it was a completely closed system.
We subsequently implemented a more custom SAAS (security as a service) mechanism for internal authentication and authorisation inside the ESB (I know it sounds bad but with iWay there are limited options) using spring security libraries and the remember me functionality which in our case met the requirements.
Low and behold our clients then changed their requirements and asked for integration with share point. This did however simplify the security model in our system because we then designed of the following:
iWay's primary security model is based around SSL certificates, it is possible to implement an SSL Provider which will manage certificates, you should therefore be able to supply share point with your SSL certificate and iWay with the public certificate and secure up the channels between the 2 servers, you can then manage users within iWay who can access the ESB on a system level and specify a share point user even specifying it's ip, this information is sent in plain text but over SSL and in our case sent between servers in the same network.
We are then leaving it to share point to authenticate users on a finer level so access to applications is managed at the share point 'portal' level and the only thing the ESB is vaguely aware of is the authorisation information which is passed with the client SOAP message and defines to what level the services can be accessed (this information is used on a service level).
Downsides to this solution are:
For each new client application developed to access the ESB interfaces a new ESB user must be configured so it is not possible for clients to be developed which can freely consume certain services on the ESB.
New clients have to implement the authorisation logic so the correctly formated authorisation string can be sent and understood by services.
Other points:
I am aware that the newer version of iWay provides a LDAP adaptor which should be able to communicate with AD so you can have your LDAP server attached to the ESB through this way so it could possibly be consumed by another client or services in the ESB but you would have to customise share point to access the information through the iWay business provider.
I also believe iWay 6 provides a SAML token provider which you could utilize (going back to what I said previous about the use of SAML) but I don't believe this fits in with a share point solution.
I would like to share more ideas seen as we are both doing the same thing, can you find me through my twitter account which is specified in my blog?
We are currently working with iWay Server Manager 6.0.1 and are also having difficulties identifying HOW to handle security for web services within this tool.
We want to build web services with it that have AD security in them like if we were using .NET Web Services and haven't found a solution. Even discussing this with the iWay staff did not clear it in our minds.
Now we have to connect to SharePoint web services and the issue will definitely be there.
Have you progressed with your situation? We would like some feedback from people using the tool on how they actually implement security with iWay.
Sorry for the delay... been quite busy over here...
Basically we've done many tests between iWay and SharePoint and we are not able to set it up to sent the NTLM credentials required by SharePoint. We've tried setting up channels, proxies and various other solutions within the tool...
We've placed a call to them to hopefully get some help...
Pascal
We are developing an app that consists of a web server that hosts a web service (amongst other things) and a client that will be communicating with that web service. Both the client app and the server are expected to be used within a corporate firewall. This application will be packaged up and deployed to organizations across the world—so it needs to be flexible enough to work in multiple types of environments.
My question revolves around web service authentication and what is appropriate for real world scenarios. I know some companies have proxy servers that require a separate authentication. How often is this a requirement across organizations? When does the proxy server force the user to authenticate (can you access internal sites without authenticating.. is the authentication for only external sites)?
Reason I ask these questions, is I’m not sure what kind of capability we should build into our client application for authentication to the web service. By default, we are taking the current user credentials and passing that up to the server. Do you think this is sufficient? In a case where a company will require some form of alternate authentication for internal access, this will not work. My question revolves around this last case—how often does it happen? Why would a company force alternate credentials for internal access?
Thanks!
Why not make it configurable? Further, use WCF and you have the ability to configure just about anything you might need, in most cases without changing your code.
If Internet Explorer can reach a site through the proxy server without prompting the user, your call to the web service should "just work". If the user is prompted by IE, you'll need to put together a way to fill in the proxy server authentication information.
I've run into quite a few problems getting web services rock solid, but never had a proxy server authentication issue.