We are currently creating a SimpleSAMLPHP based SSO/SLO implementation for an existing application based on CakePHP to connect to an Identity provided and authenticate users with accounts on the identity provider. The existing users in the application will still authenticate with their local credentials and the application will keep its session management for authentication.
I need to therefore implement an application specific SLO Soap service which logs the users out of the application, if the user logs out from another application using the same identity provider.
My question: Is it possible to change the SingleLogoutService in the generated metadata to point to an application specific soap service, which in turn logs the user out from both the service provider and the application.
We finally decided to use a different solution for the problem. The SingleLogoutService which is provided automatically by SimpleSAMLPHP is responsible for deleting the SingleSignOn Session when the user is logged out from the Identity provider. The application then checks SimpleSAMLPHP's session when the user attempts to access a protected resource and logs the user out if the user is no more authenticated with the Identity Provider.
Related
I'm using Identity Server 4 to authenticate users with WebAuthN (https://w3c.github.io/webauthn/).
I have multiple clients that that hit an api client. My api client is responsible for deciding which auth provider to use, passing data (server to server, server to external api) and orchestrating the auth process.
One auth provider we are using that we own is identity server 4 and this is where we are implementing WebAuthN.
I'm not sure which is the recommended way to implement this in Identity Server 4. I'm down to 2 options
Create an API endpoint on identity server to authenticate to users credential
Create an extension grant type and call the TokenEndpoint API using the new grant type (my extension grant type would be a mix of the built in Hybrid grant type followed by the WebAuthN code).
Are both ways valid from a security standpoint (not opening up a hole) and fit with ID4 or is there another way?
I've recently done some work on implementing this, but for second-factor only at this point.
Long story short, it needs to run in the context of the end user's browser (given that it's a JavaScript API) so really it needs to be built into the sign in flow via the authorize endpoint.
For example (assuming no local client or IDP sessions already exist):
User visits client application
Client redirects to authorize endpoint
Authorize endpoint redirects to interactive authentication UI which then decides what method to use
Do the WebAuthn challenge, validate the result and establish a session cookie
Redirect back to authorize endpoint
Issue tokens and redirect back to client
You'll also need to provide a way for users to register their authenticators. The resulting credentials are tied to the site origin so this must be done within your identityserver4 implementation - the same application that will be doing the challenging.
I have a requirement to create an admin UI where I need to list all users registered on IdentityServer to start assigning permissions and roles. This application internally uses PolicyServer, but as a superadmin user, I would need to see all users registered on IdentityServer. Here IdentityServer is responsible for authentication and the other application that uses PolicyServer is responsible for the authorization.
Which is the correct way to proceed:
1- This admin UI application should be connected to the same database that IdentityServer uses to get all the users?
2 Or should I need to extend IdentityServer on this way?:
http://docs.identityserver.io/en/latest/topics/add_apis.html
I followed this issue here:
IdentityServer/IdentityServer3#2607
but still, it is not clear for me how to proceed on the question above.
Well, the users database is usually provided by ASP.NET Identity, not so Identity Server.
I had the same issue and I went on to develop the admin Web app in the same host as Identity Server, thus using the database connection to get to the users (and the API resources, clients, etc.).
I argue that this is the simplest way to achieve what you want. And still allows you to provide a complete API on your Identity Server for external apps. I also did that (for scenarios where client apps are allowed to view/edit the user profile, for example). The API was built using plain ASP.NET Core MVC.
I'd like to use IdentityServer4 for authentication in my ASP.NET Core MVC web application, but the user registration process seems awkward. Most web sites that require user registration don't redirect you do a separate site (e.g. Facebook, Twitter, etc.) to sign up if you're using local user accounts.
One solution is to host IdentityServer4 in the same process as my MVC client, but that is discouraged.
Are there any good real world examples of local user registration with IdentityServer4?
IdentityServer is for authenticating existing users, not really creating new users.
In our use-case, we have 3 projects playing a part:
The identity server
A protected API
An identity provider (aspnet core identity) project
Users are created by a call to the API, which creates the appropriate structures in the identity provider.
Our identity server makes calls to the identity provider when validating requests for tokens.
Our API uses identity server to protect the resources, and our identity provider to retrieve information we may need about that user that aren't contained as claims (permissions, for example).
In this way our identity provider can be shared across projects (one user base with different roles), and the Identity Server is purely for authenticating users. All user management functions belong elsewhere.
EDIT:
#peyman We're not doing anything particular ground-breaking: just using the aspnet core identity framework (http://odetocode.com/blogs/scott/archive/2013/11/25/asp-net-core-identity.aspx).
The IUserStore and UserManager are the main drivers of this. When a user is created they are assigned a role, which for us is based on which application requested the creation of that user. Our implementation of IUserStore is what will ultimately be called by IdentityServer when verifying identity, and the data provided is used by IdentityServer to build up claims. Our resource API is relatively simply protected using Policies for claim based authorisation (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/claims)
My current setup is a fairly simple one. I am running Identity Server 3 which is used to provide oauth access tokens which can be used against and a number of our web api endpoints. The identity server has custom user service which authenticates requests against a custom user table in our sql database.
We have a new 3rd party software provider, this provider requires that our users (staff in our call centre) logon to their application via a proprietary login, not against our existing user accounts. We have built an api for this 3rd party which they required for their integration, as with the rest of our api's this is secured using oauth bearer tokens via identity server.
Our staff are all locally logged on to an active directory domain. Is it possible to configure identity server to issues auth tokens for a user who is already authenticated against active directory? I like to achieve this without prompting the user for their credentials again.
I've read around and at this point I'm very lost as to the correct approach, some form of federation seems appropriate, but I couldn’t find a reasonable introduction / walkthrough to help me get started.
What is an appropriate approach and are they any relatively easy to consume primers on the subject?
Yes, you should be able to make it work. The samples contain a windows auth provider. Using this, your identity server would authenticate people in without prompting for a password. Once authenticated, it would then issue tokens same as any other auth. You may need to a bit of experimenting to get it working, but from what you've said it should work in your situation.
My legacy web forms app uses windows authentication to match up the incoming user domain\username against a custom user table. If they are registered the user Id is stored in a session variable and whenever a new shipment record is created by the user the shipment record is created with the session.userID (foreign key to the user table.)
In a nutshell mu criteria is:
Use windows authentication (no typing passwords)
Use bearer token's.
Persist the user id (primary key) from custom table to track user records etc..
Use Web api
Use EF 6
I would like to build a new Angular front end with web api 2.0 Entity Framework 6 but continue using my own user table rather that the new asp.net.Identity.
The main criteria for this intranet application was people didn't want to have to type user names and passwords, they wanted to just authenticate by the windows account. I cannot see any example of how to do this with Web API and bearer token. All examples are based around the Asp.net.Identity
I was planning on using vs2013 Webapi with the Windows Authentication Template but I am lost and cannot see any example's for Intranet apps where people do this.
I really like the idea of bearer token's and want to use then but with my own user table whilst ensuring that my user.id is used by EF when new records are created etc..
The method of authentication is determined by the web server hosting your application, not the application itself. I have done this several times myself for production-level Intranet business web applications. The setting(s) that make this happen is located in your application's web.config file. Get to know the settings in that file very well. It's important.
There are two terms to keep in mind and both have different meanings: user authentication and user authorization. You don't need some fancy framework to accomplish user authentication, given your requirements. Since you are relying on Windows Authentication against Active Directory, anyone who isn't on your company's domain won't be able to access the website, period. The authentication is handled automatically for you by the server (IIS, I assume). It's super simple. When you provision the site under IIS, just make sure that Windows Authentication is the only enabled form of authentication.
User authorization can be more granular. Even though a user may be authenticated, you still may not want them to have access. This is where your user table comes in to play. The process is rather straightforward. Once the user is authenticated by the server, the server stores their credentials into the User.Identity variable that you can access in your server-side code. You could then verify that the User.Identity.Name is in your table and generate a verification token or cookie to store on the client. In the same action, you could also send to the client the user's id. I'd store the token and the user id either in the client's sessionStorage or as a cookie. Then, for security protection, you could send this token on every server request. As long as the token is valid, the HTTP action is processed. Furthermore, when the user makes a PUT, POST or DELETE, include the user id in the request data.
Here are some helpful links:
Authentication and Authorization in ASP.NET Web API
Integrated Windows Authentication
Web API Security