We have a Custom developed application and I want to make a Connection with Filenet-P8 using Java API's but the problem is I want to fetch the Username and pswd from LTPA token. I do not have prior exp. with LTPA so I don't know how to achieve this?
A quick Google Search gave me the below link - but I do not have some of the info which is used in this link --> How to use the information in an LTPA token
It's been 1 week now and I am struggling to achieve the desired result. Please assist.
LTPA token does not contain password in any form. If you expected to connect to Content Engine using username/password authentication and use LTPA token as the source of the credentials, then this is not possible.
As you already have LTPA token, I assume you are operating in the environment where JAAS context has been established and you were able to authenticate to WAS where Content Engine is running (hence LTPA token was granted). If this is the case, you can simply use authenticated JAAS subject with CE com.filenet.api.util.UserContext:
// Obtain the authenticated JAAS subject
// For the code operating within WAS the below will work for already authenticated calls
Subject subject = com.ibm.websphere.security.auth.WSSubject.getCallerSubject();
UserContext.doAs(subject, new PrivilegedExceptionAction<Object>() {
#Override
public Object run() throws Exception {
// CE operations here
}
});
Related
client type: Spa
grant type: implicit or code(pkce)
As a user, I want to be able to get silently authenticated if I have already logged with my identity provider. If not stay on the client side just like a guest user. And if I want to login to the client I should be able to get authenticated manually through the login page.
This has both manual sign-in and automatic sign-in scenarios. How would you handle such cases in Open ID Connect?
By adding the prompt=none in client settings will silently get a new token if user has a valid session. But if not I want the user to be able to manually authenticate through the login page upon his/her wish.
If I set prompt=none this will never have any user interaction such as authentication.
tags: Silent authentication oidc, automatic login, SSO
It is quite a deep subject, and the flow typically works like this:
CLASSIC OIDC SOLUTION
User is redirected for each SPA
If signed in already at the IDP there is no login prompt
OAuth state is stored in local storage (though it is recommended to only store actual tokens in memory)
When an access token expires (or before) do an iframe token renewal with prompt=none
When a new browser tab is opened do an iframe token renewal to get tokens for that tab - to avoid a full redirect
When the user logs out remove OAuth state from local storage
The most widely used library is OIDC Client which will do a lot of the hard work for you. See also my blog post + code sample for how this looks visually.
PROBLEM AREAS
It is worth being aware also that iframe silent renewal does not work by default in the Safari browser in 2020. Some notes on this here.
Alternatively, you can use signinSilent(). I have used it on my login page ngOnInit (since AuthGuard will anyway redirect the user to login, I thought it will be the perfect place in my scenario).
// login.ts
ngOnInit(): void {
this.authService.signinSilent().then(_ => {}).catch(_ => {});
}
// authService
public signinSilent() {
return this.userManager.signinSilent();
}
signinSilent method will return the user object if user already has a valid session with idp. else it will throw an error, probably login_required.
I'm unable to authenticate / sign-in via AzureAD when running testCafe.
const testrole = Role(
'https://login.microsoftonline.com/',
async t => {
await t
.typeText(Selector('input').withAttribute('type', 'email'), *******)
.click(Selector('#idSIButton9'))
.typeText(Selector('input').withAttribute('type', 'password'), ********)
.click(Selector('#idSIButton9'));
},
{ preserveUrl: true }
);
The above steps work fine, however after entering the password I get a message saying:
"Unable to sign in to Outlook account, Error: AADSTS900561: The endpoint only accepts POST requests. Received a GET request."
From my initial search, it seems like something to do with 3rd party cookies on the browser. However, I'm unable to find a solution at this time.
Any idea how I get around this issue?
The Azure AD product team has always reminded me that it is a bad idea to try to automate sign in like that.
They will probably detect that you are a bot and start blocking your requests, even if you succeed.
Instead, to acquire access tokens you need to use either the client credentials flow (for app-only tokens) or the resource owner password credentials flow (for delegated user tokens).
Client credentials flow: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
ROPC flow: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
You have to take good care to secure the credentials used for testing.
And use a test tenant if possible.
I'm currently working on a project where I'm trying to set up a service based on IdentityServer4 (https://github.com/IdentityServer/IdentityServer4) that authenticates users by querying a local Active Directory via LDAP.
To achieve that, I also included the IdentityServer4.LdapExtension (https://github.com/Nordes/IdentityServer4.LdapExtension) in my project. The working example from the repository works fine (https://github.com/Nordes/IdentityServer4.LdapExtension/tree/master/Sample/IdentityServer) - but the custom logic is part of the UI, and I need my service to operate without any UI.
Simply adding
.AddLdapUsers<ActiveDirectoryAppUser>(Conf.GetSection("ldap"), UserStore.InMemory)
as described in the documentation does not change the request pipeline, as the provided login/validation methods are never executed - they are only triggered with calls from the UI (AccountController). However, as I said, I don't want to integrate any UI in this service and rather use the interface which the Token-Endpoint already provides (POST request with client_id and client_secret, response with JWT).
Is there a way to integrate LDAP authentication without rewriting big parts that work out-of-the-box as desired?
From your question it sounds like you already have a username and password. Note client_id != username and client_secret != password. client_id is the identity for a client application.
The grant type you are trying to use is called Resource Owner Password when using the authorize endpoint or password when using the token endpoint.
This grant type is used to support legacy systems and is not recommended for new development.
The code that you want to executed to authenticate a user is in LdapUserResourceOwnerPasswordValidator.cs and it should be executed if you pass the correct parameters to the token endpoint:
POST /connect/token
client_id=yourclientid&
client_secret=yourclientsecret&
grant_type=password&
username=yourusername&password=yourusernamespassword
See token endpoint documentation: https://identityserver4.readthedocs.io/en/release/endpoints/token.html
You can use Identity Model to help you make the token request:
var response = await client.RequestPasswordTokenAsync(new PasswordTokenRequest
{
Address = "https://demo.identityserver.io/connect/token",
ClientId = "yourclientid",
ClientSecret = "yourclientsecret",
UserName = "yourusername",
Password = "yourusernamespassword"
});
This is documented here https://identitymodel.readthedocs.io/en/latest/client/token.html
I'm trying to build a (C#) web app that allows clients to make appointments with me.
I'd like the web app to be able to read and add entries to my outlook calendar.
Many users will use the web app, but the web app will only access one outlook calendar - mine.
All of the examples I have been able to get working have involved the web app user interactively authenticating - but my users will not know my password.
I would like to hard code my username/email address and password in the web app.
When trying to acquire a token I get an error:
Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException:
AADSTS65001: The user or administrator has not consented to use the application.
Send an interactive authorization request for this user and resource.
I am not an administrator of the tenant. Is there any way I can get this to work without administrator involvement?
Would using some kind of certificate rather than a user name and password as user credentials help?
My code (currently in a simple C# console application) is as follows:
UserCredential uc = new UserCredential(MyUsername, MyPassword);
var AuthContext = new AuthenticationContext("https://login.windows.net/Common");
// this doesn't work unless an unexpired token already exists
ar = AuthContext.AcquireToken("https://outlook.office365.com/", MyClientId, uc);
// this does work, but requires the app user to know the password
ar = AuthContext.AcquireToken("https://outlook.office365.com/", MyClientId, new Uri(MyReturnURI));
To enable use the username and password to request the token directly, we need to consent to use the app.
We can use the OAuth 2.0 authorization code grant flow to grant the consent by user. Here is an sample use the ADAL authentication library(3.13.1.846) to acquire the delegate token:
static string authority= "https://login.microsoftonline.com/common";
public static string GetDeligateToken(string resource, string clientId,string redirectURL)
{
AuthenticationContext authContext = new AuthenticationContext(authority);
AuthenticationResult authResult= authContext.AcquireTokenAsync(resource, clientId,new Uri(redirectURL), new PlatformParameters(PromptBehavior.Auto)).Result;
return authResult.AccessToken;
}
After we consent the app, now we can use the code in your post to acquire the token.
Until now, I have read that Rally RestAPI do not support SSO login. I believe this is no longer true as of Jan 2014. The same API is used in Rally Add-in for Excel (here is link for Rally Add-in for Excel) which support SSO login. Can I get either the source code of Rally Excel Add-in or at least someone please provide an example of SSO using Rally RestAPI?
I want to do exactly the same thing what Excel Addin Export functionality does but want to do in pure .net application.
I have added a howto to the C# Rest Api that explains how to do an SSO authentication like Rally does in the Excel plugin. I am pasting it here for convenience.
Thanks, scott
A brief Rally SSO primer
The Rally Web Services API (WSAPI) natively supports only Basic Authentication. Using Basic Authentication, WSAPI sessions must be initiated with a username and password that is validated against a list of usernames and passwords stored directly in Rally. This works fine until clients begin using Single Sign On (SSO). SSO allows clients to use a single enterprise-wide authentication mechanism (like LDAP or Active Directory) to manage user credentials and passwords. Until now, using WSAPI with SSO enabled has required clients to maintain a duplicate user list (the "white" list) in Rally for all users who wish to use the Rally WSAPI. Recent changes to Rally now allow WSAPI users to access Rally using their SSO credentials and alleviate the need to maintain those users in the "white" list.
Note: Rally's current SSO implementation is based on the SAML specification which requires a user to interact with a browser to complete authentication. As such, this technique requires the user to interact with a browser, so it is incompatible with headless WSAPI clients like those that synchronize Rally with VCS and bug tracking tools.
When initiating an SSO connection, the user provides a URL that starts the SSO handshake with Rally's Service Provider (SP), later involving the client's Identity Provider (IdP), and finishes with Rally responding with cookies that represent a valid authenticated session. If that authenticated session cookie is included in any subsequent WSAPI calls, Rally will associate those calls with the authenticated user and the WSAPI calls will be authenticated. To make it easy to get access to the authenticated session cookie for purposes of WSAPI calls following a successful SAML SSO authentication, Rally looks for a parameter added to the initial SSO URL that if present will return a special web page containing the session cookie in clear text as the final product of the SSO handshake. Users can use that data to construct a cookie to be used in subsequent WSAPI calls.
Note: The example URLs below are (potentially) specific to Rally's internal SSO implementation. Since SSO is used to allow customers to provide their own authentication using their own SSO infrastructure (at least the IdP part), SSO URLs will be customer specific. Contact your Rally TAM or Rally Support for help with SSO URLs.
An original SSO URL looks something like:
https://sso.rallydev.com/sp/startSSO.ping?PartnerIdpId=pingidp.f4tech.com-29577
The special parameter is:
TargetResource=https://us1.rallydev.com/slm/j_sso_security_check?noRedirect=true
Note: This name/value pair sets the SSO RelayState in Rally’s specific SSO implementation using PingIdentity as the SSO provider. Other SSO providers may have a different parameter name used to set the RelayState. For instance, some SSO providers use RelayState as the parameter name. In any case, the value is always the same (i.e. “https://us1.rallydev.com/slm/j_sso_security_check?noRedirect=true”)
So a complete URL would look like:
https://sso.rallydev.com/sp/startSSO.ping?PartnerIdpId=pingidp.f4tech.com-29577&TargetResource=https://us1.rallydev.com/slm/j_sso_security_check?noRedirect=true
If a user navigates to this modified SSO URL, after authentication, they will be presented with a web page that contains the following:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>SSO Token</title>
</head>
<body>
<form>
<input type="hidden" name="authCookieName" value="ZSESSIONID"/>
<input type="hidden" name="authCookieValue" value="khkjhkhkhkhkjhh"/>
</form>
</body>
</html>
If the user creates a cookie based on the data contained in this page and passes that cookie along with their subsequent WSAPI calls, those calls will be successfully authenticated. Note that optional cookie data like secure and path must be inferred from call made to obtain the cookie as per the IETF specification for cookies.
So the basic process for logging into Rally from a GUI interface (again, this does not work for headless environments) for the purpose of issuing WSAPI calls is the following:
Collect the SSO URL from the user with the special parameter described above.
Launch a browser pointed to that URL.
After navigating is complete, scrape the cookie values from the returned HTML page.
Close the browser.
Construct a cookie from the cookie values.
Store that cookie for later use.
Send that cookie with all subsequent WSAPI calls.
Repeat this process if the a WSAPI call fails for authentication using this cookie. Remember that these cookies expire and you should be prepared to retry a failed call after re-authentication to create a smooth user experience.
Rally C# ReST API
The Rally C# Rest API has a mechanism integrated into it's connection framework to make this process easy for different GUI clients including automatic re-authentication following session timeout. This includes methods to parse the token page into a valid cookie. Callers of this library can implement other features such as inferring optional cookie data (like domain, path, secure, and host port) to account for situations (like test environments) where Rally does not return complete cookie data.
Connecting to Rally using the C# ReST API means constructing an instance of RallyRestApi. There are two legacy constructors that assume Basic Authentication and take username and password among other parameters. Constructing a RallyRestApi using one of these constructors will always use Basic Authentication and will never use SSO.
A third constructor takes only an IConnectionInfo object. This is the preferred way to obtain a RallyRestApi. Using an IConnectionInfo object to construct a RallyRestApi allows the caller to specify all connection information in one object that can be used for SSO callbacks and authentication sharing between multiple RallyRestApi instances.
IConnectionInfo and ConnectionInfo
To facilitate SSO authentication, the C# ReST API introduced the IConnectionInfo interface and the ConnectionInfo class. These classes represent an object that holds connection preferences and can initiate and complete a browser based SSO authentication session when requested to do so. The ConnectionInfo class implements all of the connection preferences and has methods to parse the Rally SSO landing page into a usable Cookie. This class can be used as is if only Basic Authentication is required. IConnectionInfo is there for flexibility in case the caller does not want to extend or otherwise use ConnectionInfo.
When using IConnectionInfo for Basic Auth simply create a new ConnectionInfo and set the appropriate publicly accessible fields. Use that to construct a RallyRestApi. Any authentication errors will throw exceptions.
Example:
var cInfo = new ConnectionInfo();
cInfo.UserName = "myName";
cInfo.Password = "pass";
cInfo.Server = new Uri("https://host.com");
cInfo.AuthType = Rally.RestApi.AuthorizationType.Basic;
var conn = new RallyRestApi(cInfo);
When using IConnectionInfo for SSO, the caller must implement DoSSOAuth(). Below is an annotated example.
public class MyConnectionInfo : Rally.RestApi.ConnectionInfo
{
public override void doSSOAuth()
{
// Launch a browser to the this.server URI.
// The browser will close automatically if it successfully reaches the SSO landing page
// Users can cancel the SSO handshake
// Abort if the handshake is successful, but didn't arrive at the SSO landing page
var ssoDialog = new SSOAuthDialog(server);
DialogResult result = ssoDialog.ShowDialog();
if (result == DialogResult.Cancel)
throw new Exception("SSO authorization canceled");
else if (result == DialogResult.Abort)
throw new Exception(ssoDialog.abortReason);
// Parse the SSO landing page into a Cookie and save it
AuthCookie = parseSSOLandingPage(ssoDialog.getBrowser().DocumentText);
// Infer Cookie values from SO Landing Page URL if not set
if (String.IsNullOrWhiteSpace(authCookie.Domain) || authCookie.Domain == "null")
authCookie.Domain = ssoDialog.getBrowser().Url.Host;
AuthCookie.Secure = String.Equals(ssoDialog.getBrowser().Url.Scheme,"https",StringComparison.InvariantCultureIgnoreCase);
// Set a specific port port if the SSO Landing Page URL has one
if (!ssoDialog.getBrowser().Url.IsDefaultPort)
Port = ssoDialog.getBrowser().Url.Port;
}
}
This example uses a WinForms dialog with a browser component to present the SSO handshake to the user. Remember, you can use any display technology you want to implement this part. Here is an annotated example:
public partial class SSOAuthDialog : Form
{
public String abortReason;
public SSOAuthDialog(Uri url)
{
InitializeComponent();
webBrowser.Url = url;
}
private void documentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
// We have found the SSO Landing Page.
if (webBrowser.DocumentText.Contains("authCookieName") && webBrowser.DocumentText.Contains("authCookieValue"))
{
Trace.TraceInformation("Found SSO authentication token on page: {0}", e.Url.AbsolutePath);
DialogResult = DialogResult.OK;
Close();
}
// We have landed on the Rally ALM page
// This is usually caused by a bad URL
else if (webBrowser.DocumentText.Contains("window.FEATURE_TOGGLES"))
{
abortReason = String.Format("The SSO handshake was successful, but the 'RelayState' was not correctly set. Contact your administrator to obtain the correct URL parameter to set the SSO handshake 'RelayState' to: https://rally1.rallydev.com/slm/j_sso_security_check?noRedirect=true");
Trace.TraceError(abortReason);
DialogResult = DialogResult.Abort;
Close();
}
}
public WebBrowser getBrowser()
{
return webBrowser;
}
}
SSO Example:
var cInfo = new MyConnectionInfo();
cInfo.Server = new Uri("https://host");
cInfo.AuthType = Rally.RestApi.AuthorizationType.SSO;
// This will cause an SSO authentication event
var conn = new RallyRestApi(cInfo);
// This will not b/c it will just use the auth Cookie already in cInfo
var conn2 = new RallyRestApi(cInfo);
When using IConnectionInfo for SSO, it is important to cache the IConnectionInfo object that you send to construct a RallyRestApi. After a successful SSO handshake, the resulting auth Cookie is stored in the IConnectionInfo object and will be used for all subsequent WSAPI calls made from that RallyRestApi object. If you need to create another RallyRestApi object using the same auth Cookie from a previously successful SSO login, simply construct a new RallyRestApi object with the same IConnectionInfo object and if there is an auth Cookie present, it will be used.
Retries
Authorization Cookies can expire. The C# ReST Api will detect an expired SSO Cookie and will initiate a new SSO login session as needed to obtain a new valid Cookie.
That's all there is to it.
SSO is not currently supported by our Toolkits. We use some special hacks to get it working for the Excel plugin but nothing with an interface that is user friendly enough to share with our developer community.
We are working on an OAuth solution that should make projects like this much easier to do. Once it ships we should publish a blog to show you what features it has. My personal hope is that all of our Toolkits will have support to make using OAuth simple.