I have the hope to use the token generation and management abilities of Keycloak, without authenticating against Keycloak's users but instead, 3rd party systems that do not use token based authorization.
In other words, I want to create a realm that generates tokens not for Keycloak users but for that 3rd party's users, meaning that there is no need to store users in Keycloak's DB.
Is this even possible? If it is could anyone give me some pointers?
From what I've seen the closest ability that Keycloak provides is the Identity Providers option available the Administrator console. Unfortunately and as expected, it works only for OpenID Connect and SAML which of course are token based.
I have use below link to access all user of Azure AD but it require user to login in portal.azure.com
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devquickstarts-webapp-java
I have also use below link to authenticate user but token return by it is not useful for access other API of Azure AD. Using above url code it allow to access other API of Azure but require portal.azure.com login.
https://samlman.wordpress.com/2015/06/04/getting-an-azure-access-token-for-a-web-application-entirely-in-code/
Need java code which doesnt require us to login in portal.azure.com for accessing it API
AFAIK, Azure AD implements four flows in the OAuth 2.0 authorization framework.
And if you don't want to interact with Azure manually when acquiring the access token, you can choose the Resource Owner Password Credentials Grant or Client Credentials Grant flow based on your scenario.
And normally, we need to sufficient permission to operate corresponding resource. Please share the exact resource/request you were developing and the detailed error message to help troubleshoot this issue if you still have the problem.
And this link is helpful to learn about the authentication scenarios for Azure AD.
We are implementing Single Sign On [SSO] across multiple applications, which are hosted on different domains and different servers.
Now as shown in the picture, We are introducing a Authenticate Server which actually interacts with LDAP and authenticate the users. The applications, which will be used/talk to Authenticate Server are hosted across different Servers and domains.
for SSO, I can't use session variables, as there are different servers and different applications, different domains, a domain level cookie/session variable is not helpful.
I am looking a better solution which can be used for SSO across them. Any demonstrated implementation is existing? If so, please post it or point me in the right direction for this.
You can achieve this by having all your log-ins happen on the auth server. The other applications can communicate to the auth server through a back channel. The general principle is like this:
User accesses application 1.
Application 1 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 1 then redirects the user to the log in page on the auth server with the token as a parameter on the request.
User logs in to auth server. Auth server sets a cookie, flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 1.
Application 1 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
Application 1 now knows that the user is authorised and has some basic user details.
Now this is where the SSO bit comes in:
User accesses application 2.
Application 2 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 2 then redirects the user to the login page on the auth server with the token as a parameter on the request.
Auth server sees that there is a valid log in cookie, so it can tell that the user is already authenticated, and knows who they are. Auth server flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 2.
Application 2 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
Application 2 now knows that the user is authorised and has some basic user details.
There are some existing implementations of this method, for example CAS (Central Authentication Service). Note that CAS is supported out of the box in Spring Security. I would advise you look at using an existing implementation, as writing your own will be hard. I have simplified things in my answer and there is a lot of potential for introducing security holes if you're new to this.
I will recommend you check out OAuth. It is a good Authenticaiton and Authorization protocol used by several large organizations including facebook, google, windows live and others. It may have an initial learning curve, but it is a production grade solution.
It also has libraries for Java, Ruby, PHP and a range of other programming languages.
For example, the following server side implementations are available for Java.
Apache Amber (draft 22)
Spring Security for OAuth
Apis Authorization Server (v2-31)
Restlet Framework (draft 30)
Apache CXF
Following client side Java libraries are also available:
Apache Amber (draft 22)
Spring Social
Spring Security for OAuth
Restlet Framework (draft 30)
Please refer here for more details:
http://oauth.net/2/
http://oauth.net/documentation/
The bigger question is how you are implementing single sign on. Many open source and even proprietary (IBM Tivoli) offerings worth their salt offer cross domain single sign on capability. This would be the easiest and best way to implement cross domain sso. You can configure the LDAP server you use in the sso server you choose.
Taking for instance open sso, here is an article to configure cross domain single sign on
http://docs.oracle.com/cd/E19681-01/820-5816/aeabl/index.html
To configure LDAP in open sso,
http://docs.oracle.com/cd/E19316-01/820-3886/ghtmw/index.html
Reference on the issue is presented in a neat diagram here
http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html
Depending on which offering you use, you can configure cross domain single sign on.
With this, your diagram will look like this, with the auth server being your utility to interact with sso server of your choice.
Having an auth server that communicates with sso is a sound architecture principle. I would suggest making calls to authenticate as REst end points which could be called via http from different applications.
You cannot use Rest Service .
You could use what i call a Refferer Url Authentication
Say you have a Authentication application running on www.AAAA.com
In the applications , where you want to authenticate , you could have a filter which looks for a authenticated cookie in its domain else redirect to www.AAAA.com for authentication
On Successfull authentication , you could pass the user profile information as encrypted GET / POST data back to the application
Since I have built a Java application, I have been looking for an SSO solution for it. I found a free Java SAML Connector using which you can achieve SSO in java based applications built using any java framework.
Here's the link to it - https://plugins.miniorange.com/java-single-sign-on-sso-connector
I have a Java web application. It relies on Google OAuth to authenticate and authorize users. I want to provide an API to my application which must also use OAuth. Is it possible to provide OAuth by myself without having a database of users and auth mechanism?
Has it been implemented by anyone?
The OAuth specification doesn't make any particular statements about how to authenticate (ie, login) users - just how to pass credentials to other servers, once the authentication succeeds. There's no particular reason that, at the step where other servers might put up a login box, you can't instead initiate an OAuth transaction with another unrelated server.
However, you will need to have some sort of database to link up the credentials you issue (ie, the credentials your clients will use to operate your API) with the credentials you receive from upstream servers - whether this data needs to be retained over server shutdowns, etc, will depend on whether you want your third-party clients to be able to use their credentials over a long period.
Hey all, i want to integrate my Blackberry App with Twitter, and found that the way to do it is with OAuth. The problem I have is that i would like to do the verification of this from my server as to put less strain on the device, but I have no idea how to get the OAuth PIN from the server to be displayed on the device so the user can enter it, any ideas as to how i can do this? or an alternative ?
You can't. OAuth was designed such that only the service provider can provide authentication (so that the developers don't have to store their client passwords on their database servers and if the client changes their passwords, then it would have to be managed also on the developers side too). There is only one source of authentication and that's from the service provider (Twitter, in this case). Sharing of passwords is therefore eliminated.
OAuth doesn't work on PINs but rather using Request/Access Token. Follow the Beginners' Guide to OAuth and Twitter Developer's Auth Page to see how you can incorporate OAuth to Twitter. Just to give you an heads up, you will have to register your application to Twitter.
Update For Mobile and Desktop applications, rather go through Twitter's xAuth. Here's a documentation on how to register and use your application to use xAuth.
Twitter OAuth FAQ.