Announcement Announcement Module
No announcement yet.
UAA alone, or UAA and LoginServer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • UAA alone, or UAA and LoginServer

    So, should we just consider the uaa only for OAuth requests, and login server for username/password authentication, and as two separate applications.

    Or can we still just use uaa by itself and use the URIs for username/password authentication with its ui?

    Right now I just have the uaa deployed and when I go to the /login url in my browser, I don't get the js or css files, so just the text and textfields show on white and not pretty. But I also see the message

    "If you are reading this you are probably in the wrong place because the UAA does not support a branded UI out of the box. To login to click here. If you were re-directed here by another application, please contact the owner of that application and tell them to use the Login Server as UI entry point."

    So that message seems to say to me that I need to run both the uaa as one web app and the login server as another web app.

    And one last other question regarding the login server. Does it include URI/REST addresses for username/password login via our own web application?



  • #2
    Thanks. I think at this point we have to move on. I think the uaa and login server is exactly what we should use. But I can't quite figure out how to customize what would be different. So we have decided to use a simple Spring Security solution for our needs. In which when a user logs in we return an Access Token for that user so that the Flash and mobile device apps can pass them to login to our game server and such.

    Thanks again for your help. We will be back later when we have to add the OAuth stuff back in.



    • #3
      Yeah, it ended up working perfectly and simpler to just use standard Spring Security and use RememberMeService for the "access token and authentication in our other apps (single signon) and we wrote a custom PersistentTokenRepository. Our custom repo was because we are storing that data in Redis instead of JDBC or in-memory.

      Mobile apps will also be able to login with a simple web login form in a UIWebView like mobile component, to do the authentication and creation of our cookie with the token and series id. Then any other apps like our Socket connections can send the token/series id when first connecting and we can look that up in the Redis database to see that they are indeed already logged in.

      Thanks for the help before.