I'm currently designing a Service oriented architecture, and actually I'm facing how to design the login system.
What actually I came out with is:
webUI (client that performs several operations on other services)
loginService (stores user credentials)
other services...
Since the WebUI is one of the way to access services it makes sense to me have the login to be a separated service, so also designing access to specific services can be easily implemented.
But I'm not really sure if this is a good approach to design a login system, that most of the times will be accessed by the web interface. It could also be integrated inside the webUI itself, exposing some way to authenticate users trying to access other services directly.... What do you think about this?
I hope that's clear what I'm trying to do, if not please ask me and I'll update this post with the info you need to better understand. Thanks.
A couple of related scenarios:
Actual users authenticate and the application subsequently calls web services on their behalf
A system calls the web services
For 1, you can provide a web login as you suggest. You can then use the UsernameToken profile for web service authentication. Alternatively, you can explore a SAML-based SSO solution depending on your requirements, and send a SAML token to the web service.
Look into an STS for the second.
Related
As part of a process to update/secure/centralize our auth and licensing process, we are looking at using OIDC via Auth0. Part of our package is a web site that is typically hosted on customer networks. We are trying to figure out the appropriate flow to use in this situation. It seems like we would need to set up an appropriate Callback URL for the applications which would need to point at the customer hosted instances.
Is there more appropriate flow that doesn't require that callback? What is the appropriate way to handle that?
Sadly you will always need a Callback URL when it comes to the authentication workflow that way you know where to redirect users after login. I have attached documentation supporting this process. I hope this helps you in your adventure!
https://auth0.com/docs/users/guides/redirect-users-after-login
I'm looking to employ Thinktecture's IdentityServer3 solution as a SSO service across multiple web application the organisation makes available to external users.
Taking the MVC Authentication sample as a starting point I'm looking at bolting on a registration process for new users to capture extra details when they first come to use the systems. This process is common across all the services we provide so I wish to bundle it alongside our SSO service.
Is there an elegant way to inject extra business logic into the IdentityServer3 core service? Basically if they're a new user I need to redirect them to some registration pages before flicking them back authenticated to the web application that they originally wanted to authenticate against.
Both docs
https://identityserver.github.io/Documentation/docsv2/advanced/userService.html
and samples
https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/CustomUserService
cover this.
We are running two restful apis, one with http and the other is with udp.
They are running on premise infrastructure and within next few release, we'd need run them as google container once we dockenize them
Before we put the service up in cloud and all that, we need to implement oauth!
My question is that where to start and how we should approach implementing oauth 2 considering the road map I described?
Truly appreciate any suggestions.
It kind of depends on what you want to use OAuth2 for.
One option is toThere are OAuth2 implementations for most languages (e.g. https://cwiki.apache.org/confluence/display/OLTU/Index)
This allows you to keep your own login/password system.
If you'd rather delegate the auth and identity to a provider like Google, then you just need to implement the OAuth2 dance to get a user's identity from Google, see https://developers.google.com/accounts/docs/OpenIDConnect for more details.
(and when it comes time to use container engine, visit us on IRC #google-containers if you have questions about containers and Google!)
UPDATE: I failed to mention earlier that we want solution that will be flexible with authenticating users from within our databases or by asking other servers to tell us if the user is authenticated. It is also worth mentioning that these other servers are not under our control so we can't enforce a specific user model.
I had a long and hard read on OAuth and OpenID but they are both not a suitable solution for our situation and will make the process harder to the user. This is something that has been solved a thousand times, yet I cannot find the solution.
What we are looking for is a framework that can be used in a REST services server to authenticate users (no third-party clients involved) with their username and password.
The solution must not pass the username and password except the first time on login and use tokens for further authentication. Even though OAuth does use tokens, it is designed to allow third-party clients access to the service-providers resources. That is not the case here, the services are for our own application only, the only thing needed is user authentication.
What do you guys think is the most appropriate solution?
Configuration:
-Spring server that provides RESTful services with our thinking going towards using Spring Security with some user management and token management framework.
-iOS Device that will be making HTTPS calls to the server.
What we ultimately want is to have the device send a login request and receive a token if the login was successful, later on make requests using that token. Just like Facebook, excluding third-party involvement.
Is there something that is ready to be configured in our server? Or should we consider building our own token management, comparison and generation software?
Is using Spring-Security with an iOS application without involving storing cookies or redirecting to pages possible?
OpenStack offers as part of it's many projects related to open source cloud... the project Keystone. Which does this pretty much exactly what you want.
You might want to check it out here:
http://docs.openstack.org/developer/keystone/
Like SO, I am gonna depend on many Open ID providers to provide user authentication and I will use my own authorization methods. but I'm still in development phase, and don't want to work with real OpenID providers currently, what approach can I use to test my users and their activities in the website (w/o TDD), to emulate real users but not really use Open ID providers.
No need to make auto-transfer of users into real OpenID servers (when moving to production mode) since the current users are just for testing purposes and Unit-test code.
I guess, I need a User Service layer which provides a higly abstracted way to deal with users, so that the move to the real Open ID providers can be smooth in the future and doesn't affect the logic of my already written code.
Using C#.Net 4, ASP.Net MVC 3, Ninject
DotNetOpenAuth provides both server and client portions of OpenID and can be used to run your own OpenID provider for local testing.
Give your site members their own OpenIDs with the provider support included in this library.
Sample relying party and provider web sites show you just how to do it.
I simply register my test id as user with various organisations. I don't see anything wrong with that. I get to see the various responses and their differences.
I found it terribly easy to code for openid consumer. Just need to understand the sequence of responses. Draw the UML sequence diagram to aid your understanding before you start coding. No need to fake openId. Otherwise, whip up an openid server yourself.
Your services shouldn't depend on OpenID. Just have OpenID plug into an authentication module to provide a local user principal. In development, you can have the auth module return a fake user principal with the permissions you desire.
In a beta environment you could turn on OpenID and use test accounts from any OpenID provider. Having to log in during the development phase will just slow down all the developers. Any authentication bug or internet outage will kill everyone's productivity.