We are doing a Cloud POC, we will have applications hosted in the cloud that can only talk LDAP. Is there any system/appliance/virtual directory in the cloud that can appear to be an LDAP server from the application side, and on the output side talk SAML/REST based over the Internet to talk to our SSO product that can authenticate users against our corporate LDAP, which is tucked inside our internal firewall?
You need to deploy an Identity provider connected to the ldap. You can adopt CAS or SAML technology.
In that wikipedia entry you can check the differents products (commercial and free software):
http://en.wikipedia.org/wiki/SAML-based_products_and_services
Most of them support Ldap as the authentication source backend.
Also Take a look on this thread:
Way to single sign on between PHP, Python, Ruby applications
The emerging SCIM (System for Cross-domain Identity Management) protocol might make more sense for the use case you're illustrating. It's intended to provide a simple REST API around an identity store so you can perform Create/Read/Update/Delete operatons. What will be available could theoritically be controlled via some policy within a SCIM server to alloy your clients to essentially interact with the backend LDAP directory.
Many products are adopting the SCIM standard now, such as ones from Ping Identity, Salesforce and UnboundID.
Related
ADFS server 2016 supports openId connect. I have external organization that hosts ADFS server , I want my web application to get authenticated from External ADFS server using openIdConnect .
Question : As per Microsoft docs . If we want to consume external organization's ADFS we should host ADFS in our organization also. My application should trust ADFS hosted inside my organization ,instead of trusting external ADFS directly.
Here I want to know why we cannot directly trust External ADFS using opendiconnect ? It seems possible. what is reason of not trusting external ADFS directly?
Both models work. If your application plans to have users from multiple organizations, it is better to have your app trust an internal org ADFS which can then be federated to multiple of these organizations with simple configuration changes. This makes the application simpler where it is dealing with only one IDP. An additional advantage for having an internal ADFS is that any authentication policy changes can be managed fully at internal ADFS layer and not potentially requiring application changes.
However, if your application is only going to support one external organization, you can do this directly in the application. Both models work for this.
Hope that helps.
Thanks //Sam (Twitter: #MrADFS)
We are developing a product that consists of a set of micro services developed as Spring Rest API, those APIs will be called using Angular JS client (not confidential client to server communication) and will also interact with each other (server-to-server communication );
We are in the stage of developing an SSO solution where we also want to implement authorization based on user roles for each API, while diving more through Spring Security, I have noticed the great support for OAuth2 standard, but at the same time I saw
Implementation for a CAS server integrated with spring client;
Now my question, why would someone goes with CAS server instead of using native spring security implementation and how roles will be passed from the CAS server?
You need to further study the concept of centralized single sign-on and different components in the architecture. Spring Security is a client library mostly used by the app to contact a server of some sort. CAS, as a software system, is a server. Your client application can use any library you like to contact the "account source" or the "identity provider" server. The server on the other hand, depending on the capabilities of the client will respond and react according to the semantics of the authentication protocol used.
Roles or more accurately put, attributes and claims are passed to the client app once tokens/tickets are validated using the CAS protocol. Other protocols more or less provide the same concept.
I've been reading security articles for several days, but have no formal training in the field. I am developing a configuration and management application for an IoT device. It is meant to be run either on an internal network, or accessed over the web.
My application will be used by IT admins, managers, and factory-floor workers. Depending on the installation, there will be varying levels of infrastructure in place. It could run on a laptop on the floor itself, on a server, or hosted in the cloud. For this reason, we can not assume that our clients will have the kind of infrastructure you might find at a datacenter or in the cloud, for example CAS or NTP.
Our application provides a REST API for client applications to gather data. We'd like to use roles to restrict what data users can access. I've gathered that a common solution for authentication is to encode the username/pass in the REST Header. However, this is completely insecure unless sent over a secure channel.
As I understand it, SSL Certification Authorities grant certs for a specific domain. Our application will have no set domain, and a different IP depending on the installation. Many web applications do not trust self-signed certs. It's not clear to me whether a self-signed application is good enough for a typical application-developer who will be consuming our interface.
With this being the case:
1) What are my options to set up a secure channel, internally or via the web?
2) Am I making assumptions about how our product will be used that damage our users' security unnecessarily?
Well you can use custom encryption to encrypt the data being sent to the applications.
You can also use JSON web tokens to secure your REST API. https://en.wikipedia.org/wiki/JSON_Web_Token. The JSON tokens could be generated by a centralized authentication server and included in all requests sent by the client applications to the server
Am trying to choose between Thinktecture Identity Server v3 and Wso2 identity server for implementing Identity and Access Management solution.
Particularly, am interested in using following features:
Single Sign-On (SSO)
Managing user identities
Connecting to central repository like Active Directory, OpenLdap, Oracle Internet Directory etc.
Active and Passive Federation
Integration with ADFS
We are a .Net based shop, so getting more inclined to Thinktecture's IS, but don't want to rule out WSO2 just because its Java (one more dependency for us)
Are there other Pros/Cons between the two?
Thanks
I'm one of the developer of WSO2 Identity server. So my answer would biased to our product :)
WSO2IS is comprehensive Identity Management platform - having support for SAML2, OpenID, XACML 3.0, OAuth 2.0, OpenID Connect, SCIM, WS-Security standards.
And it acts as an Enterprise Identity Bus (EIB) — a central backbone to connect and manage multiple identities regardless of the standards on which they are based (http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html).
Few unique features that I would like to highlight on WSO2 Identity Server are.
SSO bridging to make identity and entitlement management effortless.
Identity Federation with EIB concept.(http://blog.facilelogin.com/2014/10/wso2-identity-server-microsoft-adfs.html)
Seamless integration between internal applications and cloud apps
such as Salesforce, Google Apps, and Microsoft Office 365.
New user and group provisioning capabilities
(http://blog.facilelogin.com/2014/10/wso2-identity-server-500-provisioning.html)
Multi-option and multi-step authentication to provide flexibility in
selecting authentication options and enable robust multi-factor
authentication
(http://blog.facilelogin.com/2014/10/what-is-new-in-wso2-identity-server-500.html)
High scalability (We have a middle-east customer using WSO2 IS over
an user base of 4 million for OpenID support.)
Light-weight and Very low memory footprint. The stripped down
version of WSO2 IS can be started with 64MB Heap Size and the
standard versions runs with 96MB Heap.
Highly extensible. The architecture behind WSO2 IS is highly
extensible. You can easily plugin your authenticators, user store,
provisioning connectors etc...
Support for multi-tenancy.
Suport for multiple user stores (AD, LDAP, JDBC)
Interoperability.
Part of a proven SOA product platform provided by WSO2.
single sign-on (SSO) for web applications (used through a browser) is well-documented and established. Establishing SSO for Rich Clients is harder, and is usually suggested on the basis of Kerberos tickets, in particular using a Windows login towards an ActiveDirectory in a domain.
However, I'm looking for a more generic solution for the following: I need to establish "real" SSO (one identity for all applications, i.e. not just a password synchronization across applications), where on client's side (unmanaged computers, incl. non-Windows), the "end clients" are a Java application and a GTK+ application. Both communicate with their server counterparts using a HTTP-based protocol (say, WebServices over HTTPS). The clients and the server do not necessarily sit in the same LAN/Intranet, but the client can access the servers from the extranet. The server-side of all the applications sit in the same network area, and the SSO component can access the identity provider via LDAP.
My question is basically "how can I do that"? More specifically,
a) is there an agreed-upon mechanism for secure, protected client-side "sso session storage", as it is the case with SSO cookies for browser-accessed applications? Possibly something like emulating Kerberos (TGT?) or even directly re-using it even where no ActiveDirectory authentication has been performed on the client side?
b) are there any protocols/APIs/frameworks for the communication between rich clients and the other participants of SSO (as it is the case for cookies)?
c) are there any APIs/frameworks for pushing kerberos-like TGTs and session tickets over the network?
d) are there any example implementations / tutorials available which demonstrate how to perform rich-client SSO?
I understand that there are "fill-out" agents which learn to enter the credentials into the application dialogues on the client side. I'd rather not use such a "helper" if possible.
Also, if possible, I would like to use CAS, Shibboleth and other open-source components where possible.
Thanks for comments, suggestions and answers!
MiKu
Going with AD account IS the generic solution. Kerberos is ubiquitous. This is the only mechanism which will ask you for your credentials once and just once at logon time.
This is all feasable, you need:
A KDC
Correct DNS entries
KDC accounts
Correct SPN entries
Client computers configured to talk to the KDC
Java app using JAAS with JGSS to obtain service tickets
GSS-API with your GTK+ app to obtain service tickets
What did you figure out yourself yet?
Agreed with Michael that GSSAPI/Kerberos is what you want to use. I'll add that there’s a snag with Java, however: by default, JGSS uses its own GSSAPI and Kerberos implementations, written in Java in the JDK, and not the platform’s libraries. Thus, it doesn’t obey your existing configuration and doesn’t work like anything else (e.g. on Unix it doesn’t respect KRB5CCNAME or other environment variables you’re used to, can’t use the DNS to locate KDCs, has a different set of supported ciphers, etc.). It is also buggy and limited; it can’t follow referrals, for example.
On Unix platforms, you can tell JGSS to bypass the JDK code and use an external GSSAPI library by starting the JVM with:
-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so
There is no analogous option on Windows to use SSPI, however. This looks promising:
http://dblock.github.com/waffle/
... but I haven’t gotten to addressing this issue yet.