Suppose a client wants to be able to create a trusted profile (sort of like a digital signature). The client creates their account, fills out the application and then confirms it so an employee can verify their identity and create the trusted profile.
Is it alright for both the client and employee to be in the same pool, or should they be in distinct pools such that only messages can pass between the two?
Distinct pools. There are several aspects supporting this:
The client typically does not belong to the same organisation/system, thus it should be modelled as a separate pool.
The application form is a document that is handed over from the client to the point of confirmation. The semantics of handing over a document or form is equivalent to passing a message to another party. Message passing makes it very explicit, which data is being passed. When using sequence flow, it is less clear (although you could attach a data object to the flow).
Besides of those points, I stumbled upon the first "Logging" task, which seems to be modelled from a very technical perspective. I'd rather model an activity "Check if client account exists", then have a gateway that decides whether an account needs to be created or not and then proceed. The case that the account is not existent is IMO a very valid case from a business perspective and not to be considered an exception/error.
Related
I am trying to understand statelessness in restful APIs in the context of authentication. Here's the scenario:
The user logs in.
The server verifies the username and the password, and generates an opaque access token. It caches some information related to this token - for example, the expiration time, the userId, whether this token was explicitly invalidated before it expired, etc.
The token is sent to the client, and the client sends it with every future request.
List item
Fielding's dissertation defines statelessness as:
"...such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client."
In my example, the client is sending the token with every request, so the first condition is satisfied. However, my server has a context associated with this session that is stored in the sessions cache.
Does this make my application stateful?
If yes, then is it that true statelessness be achieved only if we are using JWTs? I am pondering upon this as JWTs are quite new, so how were architects building truly stateless services before they were invented?
That's right. If you you maintaining the session you are keeping the state in server which makes the application hard to scale. True stateless applications can be scaled out and any server should be able to handle the request.
JWT is popular way to avoid sessions and everything is encapsulated inside the token for any server to auth/Authorize the request and help us achieve stateless application, they come with their own challenges however OpenID connect is the new way for Auth/Authorization.
Before jwt to make application stateless we used to keep session in DB (or Shared Cache) , and any server would like to check the session would have to contact DB.
Hope that Helps!
Briefly: No, such usage of token does not make your application stateful.
Detailed: When we talk about stateless/stateful, we consider usually only the data that affect business logic. Business logic does not usually depend on authentication data. For example, a user sends a request that contains all data needed to place some order. Normally creating an order does not depend on when this user has logged in, on his user ID, etc.
Suppose we have a number of (stateless, HTTP-based) (micro)services and a bunch of "daemons", which do all kinds of background processing by actually using said services.
Now, I want to have a way for services and daemons to be able to mutually authenticate and authorize. For example, a daemon that performs full-text indexing of Orders needs:
Read-only access to the Orders, Customers (which itself needs read-only access to Companies service) and Inventory services
Read and write access to the OrdersSearch service in order to be able to update the full-text index.
There are also applications, which operate "on behalf" of the user. For example, Inventory web app needs read and write access to the Inventory service, but the Inventory service itself needs to verify permissions of the user operating the application.
All that said, how do I achieve what I just described? I'd prefer not to use gigantic enterprisey frameworks or standards. From what I've read, Two-Legged OAuth2 is what I need, but I'm not exactly sure.
I was thinkinking of establishing an Authorization service which will be used to answer questions like "Hey, I'm Inventory service. What permissions the Customer service that is calling me right now has for me?", but that has two major weak with distributing shared secrets.
Authentication:
I imagine an authentication service where a requesting API signs its request using an established protocol: e.g. concatenating parts of the request with a expirable-NONCE and application ID then hashing it to create a signature. This signature is then encrypted with a private key. All requests must contain this encrypted signature and the NONCE as well an application identifier. The receiving service then does a lookup for the requesting application's public-key. After verifying the NONCE has not expired, the receiving service decrypts the digest using the public key and verifies the signature is valid (by repeating the signing process and coming to the same signature). A service would be required for obtaining the public key. A service can cache the application ID to public key mapping.
Authorization:
This can be done using some sort of role based access control scheme. Another service can be used to lookup whether the requesting service has access to the resources being requested.
I think both the authorization and authentication can be done internally, depending on time and money and need for specialization. If you are using Java take a look at Spring Security. If you decide to create custom code please justify it to your managers and get buy in. Do a thorough search online for any other solution and include in your write-up as to why it would not fit and that a custom solution is still required.
I'm looking into crafting an app with DDD+CQRS+EventSourcing, and I have some trouble figuring out how to do user auth.
Users are intrinsically part of my domain, as they are responsible for clients. I'm using ASP.NET MVC 4, and I was looking to just use the SimpleMembership. Since logging in and authorising users is a synchronous operation, how is this tackled in an eventually consistent architecture?
Will I have to roll my own auth system where I keep denormalized auth tables on the read side? How to handle the security of this? Will I end up storing password hashes in both my event store and my view tables?
So many questions, if anyone can shed some light, I would be very thankful :)
tldr; How do you do User Auth in EventSource-applications?
Not every "Domain" or business component has to use DDD or CQRS. In most cases, user information is really cruddy, so you can usually not use DDD for that. Other domains don't really depend on the actual user. There's usually a correlation id (UserId) that gets shared by the various domains.
If using messaging in your system, one option is to register and manage users without CQRS, then send a command (RegisterUser { UserId } ). This would publish an event User Registered. Other domains can listen to this event to kick-off any workflows or ARs that are needed.
For our MVC CQRS app, we originally started off keeping all the user related information in the domain, and, like somebody mentioned, there was a RegisterUserCommand and a UserRegisteredEvent. After storing the user information in the domain, that event got published and picked up on the read side, which also created a user and generated all the password hashes, etc. We then done the authentication on the read side: the controller would make a call out to a 'read model authentication service' to authenticate against.
Later on down the road, we ended up completely refactoring this. It turned out that we needed access to the user related information to build in security for authorising our commands, which we done on the command processing side (our app is a distributed app that sends 'fire and forget' asynchronous commands to a queue, with an autonomous listener on the other side). The security component then needed a reference to our domain to go and get the user profile, which led to cumbersome referencing issues.
We decided to put the user security stuff into a separate database that we considered to be more of a central component, rather than belonging to the domain or read model. We still maintain user profile related information in the domain and read models (e.g. job title, twitter account URL etc.), but all the security related stuff, like password hashes, are stored in this central database. That's then accessible with a service, that's available to both MVC and the command authoriser.
We didn't actually have to change anything in the UI for this refactor, as we just called the service to register the users from the register user command handler. If you're going to do it that way, you need to be careful here to make your user service related operations idempotent. This is so that you can give your commands the opportunity to be retried without side effects, because you're updating 2 sources of information (the ES and the user database).
Finally, you could of course use the membership providers for this central component, but there can be pitfalls with that. We ended up just writing our own - it's pretty simple to do. That article links to this, which provides a good example of how to implement it.
You should consider creating separate entities like: visitor (just visited your site), user (registered), customer (bought something), etc. Try to split your system in this way, even if it causes a little bit of data redundancy. Disk space is not an issue but ability to modify different components of the system independently is usually very critical.
People create denormalized auth tables only for the purpose of scaling and only if your auth read side is a performance bottleneck. If not - usual 3rd normal form is a way to go.
In SimpleMembership scenario all tables created by SimpleMembership can be viewed as snapshot of "user" aggregate. And yes, they will duplicate some data in your event store.
You may have events like: UserCreated, UserUpdated, UserAssignedToRole, etc.
And don't be tricked by the name of that membership provider. It's not so simple and usually has lots of things that you can easily live without (depends on your domain). So, maybe you can use something like this: https://gist.github.com/Kayli/fe73769f19fdff40c3a7
I need to create a some SAML 2.0 assertions, and I'm having trouble finding what the XML should really look like. Most of the documentation seems to be about using particular tools, not about the messages. I've got the schemas, with a plethora of possibilities, but I can't find an example of what the relevant messages actually look like in practice.
The business rule says: in order to create a shared identity, the user tells system A their username and password on system B. System A needs to communicate this info (along with some demographics) to system B. System B validates the information and passes back a unique identifier which can then be used to refer to this user.
Could someone give me an example of what SAML 2.0 assertions would look like to carry this information?
FWIW, I'm using C#, and need to pass the XML around in ways which preclude using a 3rd-party tool.
I'm not sure your use case is quite what SAML 2.0 does.
What you describe as your business rules actually looks like a use case for identity provisioning, not access management.
Standard SAML 2.0 use cases focus on one party asserting identity (the identity provider) and the other party (or parties) relying on those assertions (the service provider). Assertions carry what's called a name identifier, use of which is agreed ahead of time between the identity provider and the service provider.
These name identifiers can be pretty much anything, but they broadly fall into two categories: transient and persistent. A transient name identifier is only useful in the context of the current session (and essentially only says, "I know who this person is") and tends to be used to protect the identity of the principal while allowing privileged access of some type. A persistent identifier can either be opaque (in a similar way to how OpenID is used to access SO) where the asserting party can repeatedly verify a principle's identity without disclosing their identity while maintaining a dynamic but stable shared identifier between the asserting and relying parties or more substantial, such as an Active Directory UPN (which can be pre-agreed ahead of time).
When it comes to passwords, as you mention in your question, the service provider (relying party) never sees the users password. The service provider hands the user over to the identity provider with an authentication request. The identity provider sends the user back to the service provider with a response, which in the case of successful authentication contains an assertion about the identity of the user in the context of the relationship between the identity provider and the service provider.
In context of your question, the big thing is that SAML 2.0 does not provide a way to either create the local "application" user account or link that local user account to a federated identity. This is simply not the problem SAML 2.0 tries to solve.
Now, back to your business rules...
It looks to me like what you're trying to do is either account linking or registration - I would approach it like this:
User visits application, clicks a button to use identity from the identity provider
The application produces an authentication request and directs the user to the identity provider, carrying that authentication request
The identity provider either logs in the user or reuses an existing identity session if the user has one. The IdP produces a response message containing an assertion about the user. In your case this assertion should at minimum carry a persistent name identifier. The identity provider directs the user back to the application, carrying the response message.
The application processes the response message. If a mapping entry exists for the persistent identifier passed the user is recognised from that mapping and logged in as that local application user. If no mapping entry exists the user can be asked to locally log in, and on successful local login the mapping entry can be produced, or a user account could be automatically created and the user could be asked to enter additional information (names, email addresses, etc.) The "corporate" use case would be that no automatic account linking or creation is allowed and that the mapping must exist ahead of time.
As for the content of the messages...
The OASIS Security Services Technical Committee has a zip file download available with extensive documentation of the parts of the XML schema, including examples. It's also well worthwhile reading the protocol and profile documentation, as these describe the flow of messages between the parties involved in the identity conversation.
There are a large number of presentations floating around that I found very useful. Specifically, SAML v2.0 Basics by Eve Maler helped me start realising what problems SAML v2.0 was trying to solve. This presentation includes examples of that assertions look like. There is an updated presentation and links to additional resources on saml.xml.org.
I'm not sure if any of this is going to help though, as your use case does not seem to be what SAML 2.0 is trying to do. You can add attributes and extensions as needed to requests and responses, but I can't see many identity providers doing anything with those attributes and responses.
This question crossed my mind after I read this post:
“Common REST Mistakes: Sessions are irrelevant”
If sessions are indeed discouraged in a RESTful application. How would you handle licenses in such application. I'm specifically referring to concurrent licenses model and not named licenses. i.e. the customer buys X licenses which means the application may allow up to X users to be logged in simultaneously. Which means that the application must hold a state for current logged in users.
I know I can create a resource called licenses, which will set a cookie or generate a unique ID, and then the client will have to send it with every request. But it's the same as creating a session, right?
If I'll adopt the stateless approach and ask the client to create an authentication token for every request how will the application know when to consume and release license for that client?
Is there an alternative? specifically a more RESTful alternative?
Let me try to connect the dots for you, assuming I interpreted your question correctly.
The link you posted has a valid answer, each request should use a HTTP auth. If you need the concept of licences to maintain a certain state for your user, you can most likely link that to the user. You have a (verified) username to go by. You just need to invoke that controller for each request and save its state. There you have your session.
Cookie input should never be trusted for any critical information, but can be very useful for extra verification like a security token. I think adding a random security token field to your on-site links would be the restful approach to that. It should expire with the 'session', of course.
You may want to consider pushing the license handling concerns down the infrastructure stack one level. Sort of like an Aspect Oriented Programming (AOP) approach if you will. Instead of handling it in the application tier, perhaps, you can push it in to the web server tier.
Without knowing the details of your infrastructure, it is hard to give a specific recommendation. Using the *nix platform as an example, the license handling logic can be implemented as a module for Apache HTTP server.
This approach promotes a separation of concerns across your infrastructure stack. It allows each layer to focus on what it is meant to. The application layer does not need to worry about licensing at all, allowing it to focus strictly on content, which in turn keeps the URL's clean and "RESTful".
If your licensing is based on concurrent users, implementing HTTP digest is trivial, and will let you enable only the maximum number of concurrent logins. Digest has provision for passing expiration data so your session can be timed-out.
Authentication state is hold by http authetnication and nowhere else, beause it is transparent and ubiquituous.
Maybe a more RESTful way of doing licenses would be to limit the rate at which requests are handled, rather than the number of concurrent sessions. Keep track of the number of requests in the last hour, and if it exceeds the number the customer has paid for, serve a 503 Service Unavailable response, along with some text suggesting the user try again later.