I'm working on configuring SSO on websphere server to signin users to Maximo application running on that server, based on this docs: https://www.ibm.com/docs/en/was/9.0.5?topic=users-saml-web-single-sign
I have few issues that i'm not able to resolve or i'm missing some crucial information:
On the step to add trusted realms AdminTask.addTrustedRealms() i need to pass realm name that will be trusted, yet it's not Azure Term, so i don't really know what i'm supposed to pass here, i've tried adding all domain names that my company is using and it didn't work nor any other thing that could be treated as "realm"
There's no information about how to sync user registry, nor which registry type should i use? Should it be federated repositories or standalone custom registry? Without that, i'm not able to map user roles to any users from AAD
After configuring rest of SAML SSO configuration and trying IDP-initiated SSO it's able to reach out to maximo application, then it gets into infinite loop between maximo app and microsoftlogin page, while trowing 401 error. In maximo logs there's message "Authorization failed for /UNAUTHENTICATED while invoking (...)accesstokenprovider is not granted any of the required roles "maximouser" - i'm pretty sure that's because i cannot add user roles mappings to any of the users from AAD as stated in bullet point 2.
The realm mentioned in question 1 is the SAML issuer name, I guess it maybe the same as EntityID in IdP metadata
Related
I have followed the solution explained in the Azure SSO related question in the forum
After that i checked in the Portal Azure try testing from the portal itself but it keeps redirecting me to the login page only if doing it first time so its new to me though. am i missing something or i need to write login handler for my application to handle this as for now i have not created any handler for login because as per the description in the link it supposed to work .
I tried by having dd in the service provider that has been created but its not reflecting as i am confused and stuck here i am not getting where i need to write the logic where i need to handle users with type in this as for login now it is redirecting me to login route when i test it from azure portal.
Any guidance on this would be helpful !
• I would suggest you follow the Github documentation below for configuring the lavarel SAML SSO in Azure AD as it uses Lavarel package for SAML2 integration as a service provider itself. Also, as you have added the service provider in your case, it doesn’t need to if you are using v 5.5 and higher of Lavarel as it gets automatically registered. Its just for older versions that you need to add the service provider in ‘config/app.php’.
https://github.com/aacotroneo/laravel-saml2
• Thus, once you do the above and publish the config files accordingly by executing the php commands, then you will need to modify the IDP settings in PHP app’s configuration and in here, please ensure that you are entering the ACS(Reply) URL and Identifier (Entity ID) from the Azure AD created application correctly. Also, ensure that the required SAML URLs and certificate keys are correctly entered in the environment variables required in the aad_idp_settings.php
Also, please check the actual routes in the metadata, by navigating to ‘http(s)://{laravel_url}/{idpName}/metadata’ as they must be reachable for your application to pass the authentication claims to AAD for get the authentication token and since, you are configuring SSO, please check the IDP metadata for ‘http(s)://{laravel_url}/single_sign_on/mytestidp1/metadata’ and finally please ensure that ‘RedirectIfAuthenticated.php’ is configured to redirect to ‘/routesPrefix/myIdp1/login’ and the same in '/Exceptions/Handler.php'
By following the above steps, your issue should be resolved.
Short description:
Im using laravel application which already has system for logging in with microsoft account. That system works, but this is the first time im working on it, and i can not establish locally that users can sign in with their microsoft account into the application. Because system in the application works, and i get error when logging in, the issue must be in my configuration at Azure portal.
My configuration is as following:
I have created tenant and registered app in it. My SAML config is as following:
Entity ID: https://login.microsoftonline.com/tenant-id/saml2
Reply URL (Assertion Consumer Service URL): https://sts.windows.net/tenant-id/
In my .env i have set following values:
AZURE_AD_CALLBACK_URL=/login/microsoft/callback
AZURE_AD_CLIENT_ID=id-of-the-application-in-tenant
AZURE_AD_CLIENT_SECRET=tenant-secret-key
SAML2_AZURE_SAML_ENABLED=true
SAML2_AZURE_IDP_SSO_URL="https://login.microsoftonline.com/tenant-id/saml2"
SAML2_AZURE_IDP_ENTITYID="https://sts.windows.net/tenant-id/"
SAML2_AZURE_IDP_x509="tenant-id"
SAML2_AZURE_SP_ENTITYID="https://some-app.com/"
I get following error after entering my credentials:
AADSTS700016: Application with identifier 'https://someapp/' was not found in the directory 'tenant-id'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
I have added user to the application, which i use to test login, so this error is totally confusing for me.
I dont know if i provided all neccessary info, but if some missing i will provide them.
I hope someone knows what is wrong with the configuration
The tenant id is a GUID. Have you used this or are you using the "tenant-id" string?
Also, the ACS is an endpoint in your application - not an Azure URL.
I have an MVC application (.Net Framework 4.5) which is been there for the last three years and using Forms Authentication mechanism. This application provides different accounts like Personal, freebie, Enterprise etc. For an enterprise account, we are handling everything in the same application. I.e. Suppose an enterprise called “xyz” created an enterprise account with the application, then we are providing a custom URL like “https://application/xyz/login” and from the URL we are identifying that enterprise. I don’t know the exact reason why they implemented like this as I have seen applications that are having enterprise accounts are created as subdomains (e.g. https://xyz.okta.com). Now the client asked to integrate Okta into this application.
So I looked into Okta and found SAML is the right way to do and ends up in KentorIT Authservices. Initially, I was able to integrate this with a sample MVC application and the authentication part was working fine. With some basic idea about SSO, I have started integrating kentor authsevices into my application. The challenges I found in this implementation are:
1) For Enterprise accounts, Okta configuration settings are different for each enterprise and with my current application implementation, it is not possible to set it in from the web.config. So I have tried to set it from code and I was able to integrate those settings by replacing Configuration.Options.FromConfiguration;. I’m planning to store all configuration related things(Single sign-on URL, Audience URI,Identity Provider Issuer" etc.) in the database so that I can get the information whenever I wanted and I’m assuming that “Identity Provider Issuer Id is unique for each Okta account. In an IdP initiated flow, when the user tries to access the application it will redirect to AuthServices\Acs action method and from that, I’m trying to read the configuration settings. From the request is there any way I can identify from which Okta account call came(like Identity Provider Issuer)? Currently, I set the "Identity Provider Issuer" value (and I think which should be unique for okta account) to the Default RelayState field under General SAML settings tab and I was able to retrieve it from AuthServices\Acs action methods. Does it seem to be a good idea? Please advice.
2) The Enterprise accounts are limited based on the number of licenses (say 50). Suppose if the Enterprise Okta admin intentionally added 55 users all those users can successfully authenticate the application based on the default settings. Is there any way I can handle this scenario. Do I need to keep a record of the list of users that came under a particular enterprise account?
3) From the documents I understand that Kentor authentication service is only for authentication and authorization part has to be done from the application itself. The current application implementation consists of a custom authorization attribute which checks for user permissions that are stored in the database. That should be there as it is and we have to do the authorization based on database permissions. Right?
Expecting your valuable suggestions and please correct me if I'm wrong. Thanks in advance.
Don't use the RelayState for sensitive data unless you cryptographically sign it. It is not protected by any signature when using the POST binding, so the user may manipulate it. To get the issuing idp, check the issuer field of any claim generated by AuthServices instead.
Yes.
Yes, that's the whole idea with Kentor.AuthServies: To plug SAML2 authentication into the security model of .NET to allow you to use any current/traditional Authorization setup.
Background
I have a Web API registered in Azure AD and secured using WindowsAzureActiveDirectoryBearerAuthentication (OAuth2 bearer token). This is a B2B-type scenario where there are no interactive users - the applications calling the API are daemon-like background apps. As such, I don't need any consent experience - I just want trusted applications to be able to call the API, and other applications - even if they present a valid OAuth token - to be denied.
What I've tried
This sample seemed to describe my scenario almost exactly. However, the way it determines if a caller is a trusted app or not is by comparing the clientID presented via a claim by the caller to a hard-coded value. Obviously you could store the list of trusted clientIDs externally instead of hardcoding, but it seems like I should be able to accomplish this via configuration in the AAD portal so that a) I don't have to maintain a list of clientIDs, and b) I don't have to write my own authorization logic.
It seems like I should be able to define a permission for my API, grant that permission to each calling app in AAD (or a one-time admin consent), and then in my API just check for the presence of that permission in the scp claim.
From looking at the portal it seems like this is what Application Permissions are intended for:
I can create a permission just fine via the application manifest. Unfortunately, I can't figure out how to specify that it's an Application Permission, not a Delegated Permission! I tried changing the type from User to Admin as described on MSDN, but that seemed to have no effect.
"oauth2Permissions": [
{
...
"type": "Admin",
...
}
Question
Am I correct that Application Permissions are the best solution for my scenario? If so, how do I configure it? Or, as I fear, is this yet another feature that is On The Roadmap™ but not currently functional?
Ben, Application Permissions are declared in the appRoles section of the manifest. Indeed, if you declare an appRole called say 'trusted' in your resource application's (storage broker demo) manifest - it will show up in the Application Permissions drop down there. Then, when you assign that Application Permission to the client app - the access token that the client app will receive using the client credentials OAuth flow will contain a roles claim with value 'trusted'. Other apps in the tenant will also be able to get an access token for your resource app - but they wont have the 'trusted' roles claim. See this blog post for details: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Finally, the above way to assign an application permission to a client app only works when both the resource and client application are declared in the same directory - if however these apps are multi-tenant and a customer will install these apps separately - a global admin from customer's directory will need to consent to the client app - which will result in the application permission getting assigned to the instance of client app in the customer's tenant. (my blog post covers this too)
Hope this helps.
ps: if you're stuck - feel free to ping me on the contact page of http://www.dushyantgill.com/blog
We are having a hosted web application and it uses forms authentication.
This webapplication is accessed by users belong to different partner organizations.
Currently users belong to the partner organizations are accessing the application using the credentials that we give it to them.
Now, some partner organizations wants their users to access the application using their active directory credentials.
We are planning to use ADFS for these partner organizations, so the users will be authenticated using Active Directory within their network and claims will be sent to the webapp via the Authentication token cookie set by the ADFS. From the claims, we map the users to the internal userIds of the web application.
My questions are , if we make the web application ADFS enabled,
1)Is it possible to still allow the other partner organization users(who don't want to use ADFS) to login to the web application using the existing login page(forms authentication)?
2) Should every page in the ADFS enabled webapp be accessed through https?
Any solutions or pointers would be much appreciated.
Thanks
-arul
Your app needs to require claims that describe the user, regardless of where they login from. It should not handle authentication in either case; this should be delegated to a trusted issuer, an STS. This will allow it to interact w/ users in a uniform way irrespective of where and how they authenticate. This means that you're going to need to use ADFS in two roles: that of an Identity Provider (IP) STS and of a Federation Provider (FP) STS. For users of partner companies that don't want to maintain users themselves, you'll be the IP-STS; for those that do, you'll be an FP-STS. In the latter case, ADFS will redirect users from your realm back to the partner's site where their IP-STS will authenticate them and send them to your FP-STS. It will map your partner's user ID and claims into ones that make sense in your realm. This and other information about the user will be included in the set of claims that are issued from your FP-STS. As a result, your app, only trusts your STS regardless of which scenario is appropriate for different users. Note that in this scenerio, there will be two STSs: your ADFS FP-STS and your partner's IP-STS, which may or may not be ADFS. In the other case, there will only be one STS: your IP-STS.
Not every page on your ADFS Web app needs to be accessed via HTTPS; however, everyone that's used in the authentication process should be.
This is really a non-trivial undertaking. If you want to talk about it more, please feel free to get in touch w/ me.