I need to enable SSO in my and one more application. Both applications are multi-tenant applications. (to log in, user must provide user name, password and tenant name).
Every tenant will have it's own directory in identity provider or use different IDP.
Does it make sense to authenticate the user on identity provider using tenant name beside user name and password?
Is there a IDP solution capable of providing this service? (3 parameter log in)
I would think many of the IDPs out there can be made to take in three parameters. If you are using the common SAML Web SSO spec, I don't see any problem in using SAML.
As an example OpenAM is quite customizable, free and supports SAML.
This is probably of help
https://wikis.forgerock.org/confluence/display/openam/Write+a+custom+authentication+module
Related
I have been going through lot of documentation to understand what is the standard way (if there is any) in which the java client authenticates themselves with the applications deployed on server container like weblogic, jboss etc.
After reading about JAAS & JNDI authentication documentation for weblogic, I am able to understand the flow, but no documentation answers the below queries
Are JAAS and JNDI the only available methods for authenticating java clients ?
What I understood so far is, that each application server can provide its own abstraction layer to perform authentication, for example OPSS in weblogic, but eventually they all depend on native authentication methods available in JEE framework. Please point out if this assumption is not correct.
The confusion is greatly amplified as some article mention that JAAS security doesn't exists in JEE. Is that valid for java 7+ too?
The oracle weblogic documentation I have been going through clearly states JNDI & JAAS as the standard authentication approaches, and even goes to the extent to specifying JAAS as being preferred over JNDI authentication.
https://docs.oracle.com/cd/E28280_01/web.1111/e13711/fat_client.htm#SCPRG225/
Here is clarification I got based on the material read during last two days.
Most basic thing - All application servers provided provide an identity store, that can store users & groups. Applications can refer to this identity store, as when it is deployed on the server.
A Caller or User is an individual named identity defined in an identity store.
https://dzone.com/refcardz/getting-started-java-ee?chapter=1
How the applications execute authentication?
Based on pure JEE framework, the authentication methods can be classified based on the type of application it secures:
Web Application Authentication
Declarative:
We use either deployment descriptors or #annotations to specify these authentication enablers:
a. Which options to use for rendering authentication i.e. basic (browser popup), custom form, SSL, etc.
b. Which resources(URL patterns) need authentication and authorization.
c. Which users or roles (via groups) are permitted authentication or authorization.
Programmatic
Here we make use of security methods() in built in interface HttpServletRequest.
The application(e.g. servlet) call following methods to instigate authentication from within an "unconstrained" resource.
a. request. Authenticate: A login box pops up to collect credentials.
b. request. login: This methods takes login/password without the pop
c. request. logout: Resets the user/caller identity
There are several other methods also available, that provides more details of the authenticated user like isUserInRole(whether it's in given role), GetRemoteUser(gives user name), etc.
EJB Authentication
How EJBs are authenticated??
EJBs are can also be secured in the same way, as web based apps. i.e. Either with Declarative or programmatic security. Some caveats to this statement, but those are not relevant to current discussion.
So why do we need JAAS, and what is JAAS?
To appreciate this, let's understand a practical scenario for any:
An application may have multiple authentication requirements e.g. password, certificate, authentication users from multiple security realms, perimeter authentication, etc. Do we have to code so much for every application, and type of authentication? Now, it can be cumbersome and complex create & maintain code for authenticating users based on these different techno-business requirements.
To address above situation, there has to be a Pluggable way to writing code for authentication, wherein, developers would only be responsible for mentioning(not coding) which AuthenticationProvider has to be used, and writing code to call the loginModule of that particular provider, which eventually has code to authenticate the given user/caller.
This framework of providing pluggable authentication is called Pluggable Authentication Module in LDAP world.
"JAAS" is java implementation of PAM framework. With JAAS, either updated, or additional authentication technologies can be plugged under an application, without modifying the application code as such.
After Authentication, JAAS also enforces authorization.
JEE provides libraries to implement JAAS in applications!
Is JAAS implemented in same way across different enterprise application servers like Weblogic, JBoss, etc.
Well, "It can be", "but is usually not" implemented in same way across different application servers.
This is because application server may provide its own libraries, which can be used to implement JAAS.
Hope this clarifies the JEE security model to folks who do not have development background.
We are maintaining two versions of our application from security perspective
1. SAML based spring security
2. Spring and JDBC based application security.
As some of our customers already have SAML IDP (like ADFS and GLUU) which they want us to integrate for SSO and some customer doesn't have SAML IDP.
Is there a way that both configurations can coexist and based on the customer using the application, security is imposed on the user.
For ex: if the request is coming for customer a.myserverhost.com SAML based security configurations are imposed. and if the request is form b.myserverhost.com the other webSeciurityConfig is imposed
Yes, all of this is possible. What I would suggest is implementing your own AuthenticationManager which manages multiple AuthenticationProviders (e.g. SAML, JDBC).
That's where you can insert your conditional logic for choosing the correct provider based on certain criteria.
For inspiration, look at the default implementation ProviderManager.
Out of the box the ProviderManager will iterate over all of your AuthenticationProviders and attempt to authenticate the User. If it doesn't find the User it moves on to the next one. If that's all you need then you don't need any custom implementations.
I have to build a Centralized Authentication And Authorization Service. I am trying to use the JASIG CAS. But its mentioned that its a authentication protocol.My scenario is as follows.
My application redirect to cas server on the first access.
CAS redirect the user for google authentication
User signs in with the desired email and redirect back to CAS
At this moment i need to validate the user in my local jdbc store for user enabled or not and if not already registered user, and the email domain is abc.com i need to auto register the user.
CAS redirect to the calling service
My service do the validateService api call. I would like to get the user authorities for the requested service in the result response from the CAS
Does this scenario can be achieved by CAS, if extension possible for CAS, can someone suggest how to do that, basically the classes that i need to modify
Does this scenario can be achieved by CAS
Jasig CAS is highly customizable and because it is build with spring framework and spring security you can extend it to any your needs.
basically the classes that i need to modify
classes of your interests are:
PolicyBasedAuthenticationManager
Entry point into authentication subsystem. It accepts one or more
credentials and delegates authentication to configured
AuthenticationHandler components. It collects the results of each
attempt and determines effective security policy.
AuthenticationHandler
Authenticates a single credential and reports one of three possible
results: success, failure, not attempted.
PrincipalResolver
Converts information in the authentication credential into a security
principal that commonly contains additional metadata attributes (i.e.
user details such as affiliations, group membership, email, display
name).
Jasig CAS is well documented. you should be able to find all information that you need there.
I have a Restful Java Web application which is to be deployed to a number of different environments (outside of my control) which will be using a SAML 2.0 SSO solution.
My application (which I believe is the "service provider") needs to store state generated by the user, and uses internal business logic to work out which users are allowed to view or update other user's data. In order for this to work we need to know who the user is, and what groups the user is part of. But how do I get this information?
Ideally my web app will be SSO agnostic, and would look for some configurable key headers in the http requests to get this information e.g. a SAML token in a request which could be parsed, or perhaps some custom headers specific to my "service provider".
Many Thanks
You are correct, your application is the Service Provider and you will have an external Identity Provider (IdP) to authenticate to.
Basically you need to issue an Authentication Request to the IdP (via either front channel HTTP POST or back channel SOAP/whatever they support) and use the authenticationResponse from the IdP to make your decision on whether they are who they say they are. As a rule you should be able to get the subject principal (ie username) and any group memberships from the authnResponse however exactly how this works will depend on what the IdP is or isn't configured to do.
Before you do this you will need to exchange SAML metadata with the IdP (this is generally part of being registered as a SP with the IdP) which gives both parties things like the public X509 cert for signing and validating requests.
There's a good spring library for SAML SP support, http://docs.spring.io/autorepo/docs/spring-security-saml/1.0.x-SNAPSHOT/reference/htmlsingle
you could run a reverse proxy in front of the Java web application to handle the SSO protocol part and relay user identity information to the application in HTTP headers; for SAML 2.0 there is mod_auth_mellon: https://github.com/UNINETT/mod_auth_mellon
If this is done in Java and running on a webcontainer (Tomcat, JBoss, etc.), then the agent could be implemented as a web authentication (servlet) filter (add into web.xml). The user would be typically derived from the SAML Auth response's <saml:NameID> or from <saml:Attribute> matching the userid attribute (uid,email, etc.). This user should be validated against the web app's identity repository (could be LDAP, database, etc.) and corresponding groups computed. Instead of using arbitrary headers or custom representation for the authenticated user, consider using java Principal (for users and groups) in a Subject.
The filter can then run the rest of the filter chain in a Subject.doAs(). That way, the Subject can be looked up any where in the downstream code using Subject.getSubject().
I need to query AD outside organizational boundaries from a Java application and get a list of users from that with proper authentication and privileges using ADFS and SAML.
I am new to ADFS and SAML and claim based authentication. I need to use these technologies with JAVA.
How can I integrate ADFS with java in this scenario?
ADFS doesn't offer a means to get "a list of users". For that you should look at traditional ways of querying AD using LDAP (as proposed by Aaron).
As you point out - ADFS provides claims-based authentication features, via protocols such as SAML 2 and WS-Federation. These protocols are typically used to get a security token for a user, and use that token to authenticate them at a Service Provider (external application). This interaction would be done on a user initiated basis, with them first authenticating to ADFS (acting as the Identity Provider).
It's not clear to me what your entire project entails, but perhaps that approach could be applied? If not - you may have to look at opening up firewall ports to access AD via LDAP (or LDAPS).
Here is a good place to start: http://jeftek.com/222/using-java-code-with-active-directory/