Identification of existance of Corda accounts in main controller API? - kotlin

How to identify that whether the input string is an account name or host party name from a single parameter in an API function and then route query accordingly in Corda accounts?

To check if the string name is a well-known counterparty you could use something like this
Party party = proxy.wellKnownPartyFromX500Name(CordaX500Name.parse("O=PartyB,L=New York,C=US"));
To check if an account exists with a particular input string name you could hit the vault using
Vault.Page<AccountInfo> accounts = proxy.vaultQuery(AccountInfo.class);
List<StateAndRef<AccountInfo>> accountInfos = accounts.getStates();
and check if an account with the specified input name exists in accountInfos.

Related

How to guarantee preferred_username unicity on amazon-cognito?

I am using a single table to store all my data in dynamodb as such:
Partion Key (PK)
Sorting Key (SK)
Attributes
USER#gijoe
PROFILE#gijoe
{ name: "G.I", lastName: "Joe" }
USER#gijoe
CARD#first-card
{ name: "King", picture: "./king.png" }
I am using the preferred_username as a part of the Partition Key, and thus need it to be unique to avoid colliding user data.
How can I garantee that two users in my User Pool cannot have matching preferred_username ?
Edit:
The answer from #Lukas did it. Note that it required me to drop and recreate my cloudformation stack, which is why it failed on my first tries. Now when I try to edit the preferred_username I get the error I was looking for:
{
"message": "Already found an entry for the provided username.",
"code": "AliasExistsException",
"time": "2021-01-19T09:36:47.874Z",
"requestId": "7b52dbc2-58c5-4354-aa51-66d4dc7472a0",
"statusCode": 400,
"retryable": false,
"retryDelay": 85.84051584672932
}
username is unique within single pool. Same with alias. preferred_username may be configured as username alias.
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html
Key take aways:
Developers can use the preferred_username attribute to give users a username that they can change. For more information, see Overview of Aliases.
The username must be unique within a user pool. A username can be reused, but only after it has been deleted and is no longer in use.
You can allow your end users to sign in with multiple identifiers by using aliases.
The preferred_username attribute provides users the experience of changing their username, when in fact the actual username value for a user is not changeable.
If you want to enable this user experience, submit the new username value as a preferred_username and choose preferred_username as an alias. Then users can sign in with the new value they entered.
If preferred_username is selected as an alias, the value can be provided only when an account is confirmed. The value cannot be provided during registration.
....
Alias values must be unique in a user pool. If an alias is configured for an email address or phone number, the value provided can be in a verified state in only one account. During sign-up, if an email address or phone number is supplied as an alias from a different account that has already been used, registration succeeds. Nevertheless, when a user tries to confirm the account with this email (or phone number) and enters the valid code, an AliasExistsException error is thrown. The error indicates to the user that an account with this email (or phone number) already exists. At this point, the user can abandon the new account creation and can try to reset the password for the old account. If the user continues creating the new account, your app should call the ConfirmSignUp API with the forceAliasCreation option. This moves the alias from the previous account to the newly created account, and it also marks the attribute unverified in the previous account.

joinChannel method : uid assignment

The Agora.io doc is specifing for the joinChannel method :
The user ID. A 32-bit unsigned integer with a value ranging from 1 to
(2^32 -1). This parameter must be unique. If uid is not assigned (or set
as 0), the SDK assigns a uid and reports it in the joinChannelSuccess
callback. The app must maintain this user ID.
I have 2 use cases :
For the users registered to my app : i want the app to assign an uid
For the users not registered to my app : I want to let agora.io decide of the uid
The issue is that doing so, I may get into collisions between userIds assigned by the app and usersIds assigned by agora lib.
But if you are assigning uids within a range of values (other than 1 -> 2^32) then i could rely on that.
Is it the case ?
thx.
in this case, i think you can use the string user name to join the channel. You can take a look at this doc: https://docs.agora.io/en/faq/string

Private and shared address book with LDAP?

For a set of users belonging to some organisation, I want to provide the following:
each user should have a private address book
each user should have access to a company address book
I wonder how to model this scenario in LDAP so that:
user connects to LDAP server with some client
user performs a search for some string
all matching entries from the global address book are returned
all matching entries from the user's private address book are returned
Is searching the global and private address book possible with a single query? I guess the user would provide his path in LDAP as DN, but the global address book would be located at a different DN. I imagine something like that:
/
/OU=private-address-books
/CN=user1
/CN=entry1
...
/OU=global-address-book
/CN=entryABC
So is it possible to somehow automatically reference the global address book under the user's private address book?
You would probably be best off to arrange your DIT Structure to be more like:
ou=private,ou=Addressbooks...
ou=public,ou=Addressbooks...
You then could search using the the ou=addressbooks as the baseDN.
Or better, assign an Attribute boolean type private=TRUE to each entry.
So for all addressbooks,
(objectClass=Entry)
And for private
(&(objectClass=Entry)(private=TRUE))
And then finally, you may be able to use an ExtensibleMatch search filter to search both containers.
-jim

Make openam/opensso return role name instead of role universal id

I'm using OpenAM 9.5.2 for authenticating users on an application. The authentication works well but I'm having issues to get user memberships from final application.
I've defined the group "somegroup" in openam and added my user to this group. Now in my application, I want to test if authenticated users is member of this group. If I'm testing it with:
request.isUserInRole("somegroup");
I get false result. Actually, I have to test
request.isUserInRole("id=somegroup,ou=group,dc=opensso,dc=java,dc=net");
in order to get a true response.
I know that it's possible to define a privileged attribute mapping list in the sso agent configuration to map id=somegroup,ou=group,dc=opensso,dc=java,dc=net on somegroup, but it's not suitable in my situation since roles and groups are stored in an external database. It's not convenient to define role in database and mapping in sso agent conf.
So my question : is there a way to make openam use the "short" (i.e. somegroup) group name instead of its long universal id ?
This is not an answer, just one remark.
I've performed some researches in openam sources and it seems to confirm that the role name stored in repository is replaced by universalId when openam build the request. This is performed in com.sun.identity.idm.server.IdRepoJAXRPCObjectImpl.java class:
public Set getMemberships_idrepo(String token, String type, String name,
String membershipType, String amOrgName,
String amsdkDN
) throws RemoteException, IdRepoException, SSOException {
SSOToken ssoToken = getSSOToken(token);
Set results = new HashSet();
IdType idtype = IdUtils.getType(type);
IdType mtype = IdUtils.getType(membershipType);
Set idSet = idServices.getMemberships(ssoToken, idtype, name, mtype, amOrgName, amsdkDN);
if (idSet != null) {
Iterator it = idSet.iterator();
while (it.hasNext()) {
AMIdentity id = (AMIdentity) it.next();
results.add(IdUtils.getUniversalId(id));
}
}
return results;
}
To my knowledge this is not possible currently with out of box code. In case you have limited amount of groups, then privileged attribute mapping could be a way to go, but if not, then the issue gets more complicated.
You could try to change the AmRealm implementation (authenticateInternal method) to match your requirements and hook the new class into the container-specific ServiceResolver class (like http://sources.forgerock.org/browse/openam/trunk/opensso/products/j2eeagents/tomcat/v6/source/com/sun/identity/agents/tomcat/v6/AmTomcatAgentServiceResolver.java?r=700&r=700&r=700 )
You can also create a JIRA issue about providing a config property to put membership information into roles in non-UUID format.

What is used to login in LDAP mail server?

If I added data on LDAP in this way:
$ldapserver = "mail";
$ds = ldap_connect($ldapserver);
$r = ldap_bind($ds, $ldaprootun, $ldaprootpw);
add = ldap_add($ds, "cn=$full_name,ou=$domain,o=mygroup.com", $infonew);
Then does that mean that when I log in to my account I will use:
`cn="mynameHere",ou="domainIused",o=mygroup.com`
as my username? Or just my uid?
My account cannot login but I'm sure that it exists in LDAP.
Answers are very much appreciated. =)
Typically in LDAP applications you only ned to login with your UID, not your full X.500 name.
Try calling ldap_bind() with your creds and see what it returns?
Usually, the user provides a simple name. Then the app searches the LDAP source for some attribute that has that value. Then you bind or password compare in your code, as that full DN.
You can use uid which is Unique ID, which is required to be unique. I.e. If you find more than one instance of it, that is an error.
You can try CN, but that can often be multi valued depending on your LDAP implementations schema.
If you know you are going against eDirectory, then uid is fine, or CN just do something if it is multi valued.
If you know you are going against Active Directory, you can assume sAMAccountName is unique since the system enforces uniqueness. userPrinicpalName ought to be unique, but nothing actually enforces it.
You can always use mail, which is the email address pretty uniformly.