AD FS supports OpenID Connect protocol for authenticating users. AD FS supports access policies for WebAPI applications, but not for server applications, at least not that I could find.
Is it possible to define access policy for a server application? The business scenario is really simple: only allow users from a defined group to authenticate given a specific client id.
If an enterprise deploys AD FS with AD DS and deploys several applications (each one registered separately, thus getting a unique client id and client secret), this could be used to allow/disallow users from authenticating to the ADFS for a given (registered) client (relying party).
It appears that this is possible by defining two applications in the same application group:
The server application, which has a client secret in addition to client id
The WebAPI application, for which you can define an access policy.
In order to make this work, you need to assign the relying party identifier (the client id of the server application) to the WebAPI identifiers and ensure that the "Client permissions" of the WebAPI application contain the server application.
If the access policy is not evaluated successfully, the relying party (the application requesting authentication) will receive an access_denied message.
Application group:
Server application:
WebAPI application:
Related
Currently .Net Core app has APIs with OpenID Connect configured. It gets user token and validates.
Now have a requirement to implement client credential flow for 2 APIs leaving rest with OpenID connect. These two APIs are triggered by another backend system. By providing client id,secret and grant type = client credentials , back end system is able to invoke these two APIs. But problem is it can also invoke other APIs which i don't want.
Looking for a way to achieve this in .Net Core. Please advise
If you implement client credential flow, the access token will include the Application permissions.
If you implement OpenID Connect flow, the access token will include the Delegated permissions.
In order to control which API the client app can access, you need to verify the permission.
You can learn more configuration from how to verify Application permission and verify Delegated permission.
We want to build one spring MVC based application which will support below use case:
User access the application URL to login into application.
Once the valid credentials are entered to login into application, the user can access any of the service provider application for performing SSO.
On the access of any service provider application the SAML response should be generated and post to the Service provider ACS(Assertion consumer service) URL.
Also in addition to IDP initiated SSO, it should also support SP initiated SSO where the authentication request will we posted to the application login page, after valid credentials are entered by user, the application should redirect to service provider(which have posted the authentication request).
The application should have its own login page and authentication mechanism, it should not redirect to any other identity provider for authentication.
Should we use normal Spring MVC based application which will generated the SAML response using open SAML library, or any other SAML builder can be used for satisfying the above use case.
This basically means
- your app bundles a SAMLv2 compliant IdP (please don't try to build one yourself based on some SAML lib)
- your app calls an API of the IdP for authentication and issues a session token the IdP will recognize later on (otherwise authentication will always happen again when another application (acting as SAMLv2 SP) wants to perform SSO
Issue with the latter: The "token" will most likely be a cookie and then the restrictions of the cookie spec apply. This means you can only use host-based cookies (which security mandates) if your app and the IdP are deployed behind the same 'FQDN' (e.g. by using an HTTP reverse-proxy)
Another issue: How does your app know when the show the 'login screen' if the user actually has a valid session with the IdP because SSO was started at a different SP?
SAML way: You would first have to do a 'passive AuthnRequest' to check this.
Conclusion: Your use case can be achieved, but the effort seems quite high. I'm not aware that there is some lib/framework, which would offers this at the moment OOTB.
I am working on application whose details are as follows:
Its 3 tier architecture. Web Tier (ASP.Net MVC) -- Service Tier (ASP.Net WebApi 2) -- Database Tier(MS SQL 2014).
Application will also have native mobile apps as clients which will consume Service tier.
Service Tier (Web API) uses individual username/password in conjunction with OAuth for authentication and authorization.
User details are stored using ASP. Net Identity system. ASP. Net Identity database tables are in same database as that of application database.
There will be no direct calls from clients i.e. web or mobile apps to database and every request has to go via service layer.
Users of web client and mobile apps will be authenticated against asp.net identity database which is part of application database.
I have partially implemented above architecture however facing one challenge i.e. once user is authenticated, OAuth token will be issued from service layer which will be valid for one day. But how and where should I securely store this token in Web Client (ASP.Net MVC app) so that user needs to login only once in day and not for every single request that it makes.
One option I can think of is once user is authenticated and token is received in web client then store it in in-memory session storage and use it for further requests. However down side of this is, it will reduce scalability of application and will require sticky sessions in load balanced environment.
Is there any better way I can handle this situation? Also want to validate above architecture if its correct architecture?
We have a separate web application secured with Azure Active Directory that exposes some (internal) services.
Now we want to access these services from within our site, but this fails off course because of the authentication that is not yet done.
This site doesn't use Active Directory for authentication.
Is it possible to configure this site as a trusted client (through token, key) in the web.config? So that we don't need any code modifications?
Or has this to be done through code?
Kind regards,
It looks like you have a WebAPI secured using Azure AD (what you refer to as web application) and a WebApp (what you refer to as site) that needs to access the WebAPI. If this is indeed the case, you can register both the WebApp and WebAPI as applications in Azure AD (the WebApi is presumably already registered, as it is secured using Azure AD). Then, your WebApp can access your WebAPI using its own identity (client credential OAuth flow sample code) or on behalf of the signed-in user (auth code grant OAuth flow sample code).
In either case, the WebApp (site) needs to acquire an access token to access the WebApi and send this access token in the Authorization header in every call that it makes to the WebApi - this will require code changes to the WebApp. In theory you can build a proxy application that acquires tokens and injects headers in all outgoing calls - however I doubt it would be worth the effort.
Hope this helps.
Assume there are two companies: A.NET which is a .NET shop and B.Java which is a Java shop.
Users in each company need to access the other company's web sites so the two companies set up Federation using ADFS and Oracle Identity Federation or OpenSSO Federation.
In the .NET world, the attributes are accessed as claims inside IClaimsPrincipal and IClaimsIdentity.
In the Java world, the attributes are accessed as HTTP headers.
Does the Federation infrastructure do this mapping automatically i.e.
If a A.NET user accesses a B.Java site do they get their attributes as claims?
If a B.Java user accesses a A.NET site do they get their attributes as headers?
Assuming you can use WS-Federation on both sides, then in both cases the main artifact you would be dealing with is a SAML token.
In general, your federation infrastructure is completely independent of the application stack. ADFS would issue SAML tokens in either case (for the Java app and for the .NET app). OIF would also have to issue SAML tokens for both sets of users.
In the .NET world, WIF will parse/validate, etc. the SAML token into a .NET object model that represents the information in it (the claims, the issuer, etc). That object model is the ClaimsPrincipal (and all related interfaces and types). You would have to look at the WIF equivalent on the java world. But in either case, the input is a SAML token.
In your scenario it is likely that there will be a token transformation in both STSs:
For the .NET app:
1- user from the B company authenticates on OIF and gets a SAML token for company A
2- user sends token to ADFS
3- ADFS reads the token from B, validates and issues a new token (potentially and very likely adding/transforming/removing claims)
4- user sends the transformed token to app A
The sequence from a user in A accesing the java app on B is exactly the same. Notice there's a bidirectional trust in this case (Company A trusts issuer in B and viceversa)