We have a self-developed proprietary user management and self-developed Single Sign-on. (OpenID Connect wasn't born at that time)
Our authentication server and our thick clients are in a private network, without internet access.
The task is to integrate a third-party thick client - its users should authenticate against our existing authentication server.
The general idea is to use an existing future-oriented framework which offers a standard authentication interface (like Keycloak?) and implement our own OpenID Connect authentication provider (or User storage SPI for keycloack).
Is the way with keycloack and User storage SPI recommendable or are there better approaches?
As you say, this is a good choice for meeting your immediate requirements:
External client uses a modern OpenID Connect flow - eg OIDC for desktop apps
It connects to an Authorization Server with support for standards based endpoints
Authorization Server has extensible support for data sources and can potentially reach out to your existing user data source
As an example, Curity, where I work, supports multiple data sources and there is a free community edition if useful.
Any provider that meets the same requirements would be fine though - and I've heard some good things about Keycloak.
LONGER TERM
It makes sense to then gradually update other apps to use modern OAuth and OIDC behaviour.
At a suitable point it is worth making the Authorization Server the only place from which Personally Identifiable user data is accessed, and moving the storage there. See this data privacy article for some advantages of this.
I can vouch for Keycloak User Storage SPI approach. Recently implemented this for a project and it is working pretty well. For any existing user-database I highly recommend it.
I found some example source on github that you could look at (although needed some modification to run it):
https://github.com/mfandre/KeycloakSPI
I have also written an article summarizing my findings working with Keycloak in case you're interested in other features:
https://dev.to/kayesislam/keycloak-as-oidc-provider-42ip
It's extremely customisable.
Related
I have following setup. Office365 is configured with federated identity. Let say Outlook client is trying to authenticate to Office365. It (some mix of Office365 and AzureAD) will authenticate to ADFS (using WS-Federation protocol).
I want to create simple server which mimics WF-Federation interface (so Office365/AzureAD will authenticate against my server).
I am looking for example request and response of this protocol for such a case. Just to make sure which parts of WS-Federation is used. And I will try to find open source code which covers it.
I am reading through:
http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html
On one hand it covers the whole WS-Federation. However, it has gazillion options and it's not clear which part of it is used by Office365/AzureAD/ADFS.
I'd suggest using OpenId Connect rather than WS-Federation. There is a lot more current documentation on it, and it is the preferred authentication protocol for Azure AD moving forward. You can find many examples here:
https://github.com/AzureADSamples
And this one might be a good one to start with.
https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
If you are not developing on .NET then you can use these samples to generate example messages. There are also many 3rd party libraries and SDKs for non-Microsoft platforms that will likely also work.
Could you help me determine which authentication protocol I should use for the following use case? I am new to this area of development and am a little bamboozled with all the technical information out there - so a 'for dummies' answer would be greatly appreciated.
I have an online learning website that hosts courses in English Language. A requirement has arisen that we should integrate with 3rd party Enterprise Systems (because we sell the courses to Enterprises).
The primary requirement is to allow 3rd party systems to redirect their users to my site and have them access it with there 3rd party system credentials (I believe this is called Single Sign-on?). The 3rd Party systems are obviously remote systems and I am focusing more on capability than 1 specific customer / integration.
So, what I am trying to understand, is what capability should I offer to allow this to happen? I am trying to develop a generic 'developer toolkit' so that I don't have to be bogged down in lots of individual integrations as and when they arise.
I have read that there are lots of protocols / things in this space (SAML, OAuth, OAuth2, OpenID, Shibboleth, etc) - so I wondered where I should focus my attention and research? Which is the most common among Enterprise systems (CRMs, etc)?
Also, as a sub-question. Is OAuth deprecated or sneered upon now that OAuth 2.0 is released?
Any help is truly appreciated!
Thanks all.
SAML 2.0 is the most popular protocol for Single Sign On when it comes to Enterprise systems. Most if not all enterprises are able to provide SAML based SSO for third party websites.
Ideally, if correctly implemented the enterprise would need to configure their system to send your website SAML assertions (Identity information in the form of XML) and you would the information in the assertion to log the user in.
The Enterprise would be called the Identity Provider (IDP) in this case and your website would be called the Service Provider (SP)
There are a number of open source libraries available that allow implementing SAML (Spring etc.), alternatively your existing servers may have the capability as well.
Once you have the base implementation done, you can then choose to do two things:
If the user does not exist in your DB, create a new record and allow the user access.
The enterprise that you are integrating with must supply a list of users before hand and then you can allow only the users that are present in the DB.
Although the second option has a lot of overhead and not used very often.
---------------------------- Answer to Comments-------------------------
It depends on the way you would setup the interaction.. There are two ways to setup SAML SSO:
SP initiated SSO: This means that the users always access your site and then is redirected to the IDP for authentication. The SAML token is sent back to your site post authentication.
IDP initiated SSO: This works in a way that the IDP generates a SAML token and directly posts it to the SAML endpoint of your website.
If you are using option#1 and users are already logged in step C would not be needed since the user is already logged in and the token can be directly generated.
For option#2 only the steps D and E would be needed. I would however urge you to strongly to not omit the SP Initiated SSO implementation since some IDPs do not support IDP initiated SSO.
Hope this helps
Avi
OAuth allows the you the User to grant access to his private resources on one site to another site. But how exactly does this happen. And if I want to provide OAuth features in my site, (both as Service Provider and consumer), how do I go about doing it. I'm using a Fedora 13 based server. And is it possible to configure Round Cube / Squirrel Mail to provide these Services. Like as of now all my users have mail account in the server, I want the credentials in the mail to be used to provide the OAuth Services.
If you want to be a provider of data, then you have to implement OAuth server at your site and if you want to be consumer, you will have to implement OAuth client at your site.
You should also read some articles and tutorials to gain a better understanding of the protocol, because it's a protocol that allows to protect APIs and that being said, everything connected with security should be well understood by the developer that is imeplementing it.
In case that you're a provider, the 1.0 version of the protocol works in the following way:
Consumer requires access to end-user's private data
Provider issues a token to the consumer
End-user authorizes the token
Consumer can make authorized requests with that token for end-users's private data
Good place to start is: http://hueniverse.com/oauth/
You can also read the RFC when you decide if you will implement 1.0a or 2.0 version of the protocol. I have implemented only 1.0a so far, so I cannot give advice to which is better. I guess the 2.0 version has more possibilities, and everyone says it's easier to implement. As far for the easier, 1.0a is not difficult to implement also, because there are good open source libraries both for clients and servers and you can set up and run server or client for 1 day, if you understand the mechanics of the protocol.
Of course, if you want to make a good server with different scopes of access, inheritance of scopes and if your API is complicated and extensible, you will have to do a lot more work there, no matter if you choose 1.0a or 2.0 OAuth version
A simple example to demonstrate oauth flow. Understanding the concept helps to design accordingly:
As for the "How will I do it?"
There are lots of good libraries out there. Here is an excellent list: http://oauth.net/code/
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
I have a need to implement a STS-IP server for our web applications and services. The server will need to issue SAML tokens for the following scenarios:
Business partner submits their SAML token which is converted to a SAML token with the claims required for our applications. This token is used to access our Web Applications and Services.
Our public facing applications need to have a user sign in (via forms authentication) and then access our web applications and services with a SAML token.
Our clients (without a STS trust) needs to authenticate with our STS-IP server, get a SAML token, and use that token to access our WCF services.
In all 3 scenarios, we need to have custom claims on the SAML token that our applications and services use. The thought is once we identify the user, we would look up their authorization in our back-end systems and attach claims.
In these scenarios, you can assume the back-end authentication store is a custom implementation with authentication stored in Active Directory and authorization stored in a database.
So my thought has been, we need to create a custom STS-IP server using something like Windows Identity Framework. But I have also been reading that you should not do this because it can take some time.
Can I use an off-the-shelf STS-IP server? Everything I've seen is a mapping between one system to another (SAML to SAML or AD to SAML).
Why will it "take a long time" to build a production ready STS-IP ? I built one using WIF very easily, but I guess I don't understand the risks in doing this.
In terms of "It will take a long time", the documentation showing how to do this is very poor. See here: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/257d93be-165e-45a6-a277-fc7ed2286e7d/
Anyhow, you'll simply need to look over the code samples that Microsoft provides: Google for Identity Developer Training Kit. That should help you get started.
Why are you not considering using ADFS? If the backing store for authentication is AD, then ADFS is probably a good candidate to evaluate.
Before writing you own STS, you may want to check out this blog and closely review the features that you may need in the STS. Just because you can build one yourself, doesn't always mean you should.
extending adfs to multiple identity and attribute stores
They "why not" is relatively simple: Why take weeks to build something that will probably only handle a single use-case when you can put in off-the-shelf STS in a day that will cover all sorts of things your company may come up with? Building it yourself will also require you to become an expert in SAML (which is probably not the best us of your company's time).
Check out --
http://www.pingidentity.com/our-solutions/pingfederate.cfm
Good luck -- Ian
Agree with #eugenio - why not use ADFS?
ADFS can only authenticate against AD as discussed but it can derive authorisation attributes from AD / LDAP / SQL server
The nuts and bolts for an STS are available in VS 2010 plus the identity tool kits. A simple STS can be quickly prototyped.
There are some examples available. StarterSTS is already mentioned plus SelfSTS.
The hard part is getting the security right especially if this will be part of a production system. As per "Steve on Security" Build your own Directory Federation Service:
It may sound like I think it’ll be a
synch to develop this system and have
it work securely, but in reality there
is a lot that will need to go into it
to protect the network, the employees,
and the data this could possibly
interact with. It is tough to develop
applications securely. It is far
harder to develop secure applications
whose sole responsibility is security
related.
That's the reason that all the samples on the Internet have disclaimers in bold:
Do not use in a Production environment